Abstract
Using methods and technologies of business process management (BPM) for the laboratory automation has important benefits (i.e., the agility of high-level automation processes, rapid interdisciplinary prototyping and implementation of laboratory tasks and procedures, and efficient real-time process documentation). A principal goal of the model-driven development is the improved transparency of processes and the alignment of process diagrams and technical code. First experiences of using the business process model and notation (BPMN) show that easy-to-read graphical process models can achieve and provide standardization of laboratory workflows. The model-based development allows one to change processes quickly and an easy adaption to changing requirements. The process models are able to host work procedures and their scheduling in compliance with predefined guidelines and policies. Finally, the process-controlled documentation of complex workflow results addresses modern laboratory needs of quality assurance. BPMN 2.0 as an automation language to control every kind of activity or subprocess is directed to complete workflows in end-to-end relationships. BPMN is applicable as a system-independent and cross-disciplinary graphical language to document all methods in laboratories (i.e., screening procedures or analytical processes). That means, with the BPM standard, a communication method of sharing process knowledge of laboratories is also available.
Keywords
Introduction
Modern process-driven applications cover the advanced workflow process automation, systems integration in hybrid and heterogeneous information technology (IT) environments, and improved process-guided support of human tasks and automated documentation. Here, new methods and standards of business process management allow new automation approaches in laboratories, of which challenges, concepts, and proof of principles are introduced in Holzmüller-Laue et al. 1 The conceptual framework is a model-driven development with the standardized graphical process notation BPMN 2.0 (OMG–Standard Business Process Model and Notation 2 ), which is directly executable by a process engine on the workflow automation level. The process engine calls activities according to their ordering in the process model and taking into account process states. Thereby, the activities are parallelized and synchronized. Here, both development and execution form a unique new development environment called BPMS (business process management systems). Depending on embedded information and automation systems, the process engine triggers activity-related messages, signals, visualizations, web forms, or automated subprocesses.
The automating of end-to-end processes is a chance for more efficiency and transparency in the laboratory automation, but at the same time, it is a challenge, because several existing systems (e.g., instrument control systems, information systems) and data sources must integrate. Suitable interfaces, standards for protocols, and data formats are required to do this. In extension to Holzmüller-Laue et al., 1 we discuss here aspects of the implementation and systems integration within a composite application. The focus of this article is on the synergy of business process management systems and generic process documentation platforms using an example of a laboratory information management system (LIMS). LIMS are unique, established tools for the documentation and archiving of experimental measurements and results. In the presented approach, the LIMS also takes over the detailed logging of workflow for each experiment run. The available runtime information facilitates the process improvement. The presented LIMS is an in-house developed, web-based system with integration interfaces to higher-level systems (e.g., BPMS) and lower-level systems (e.g., laboratory instrumentation for data import). Thus, LIMS is a service consumer and service provider at the same time. The discussed implementation of the BPM-driven workflow automation is transferable to other IT environments and LIMSs.
End-to-End Processes
BPM technologies are directed especially to control, record, and monitor complex and often changing end-to-end processes. The process transparency in life science laboratories extends over any detailed processes of the hierarchical automation system in the laboratory and all necessary professional networking of the involved interdisciplinary teams or customer relationships. The combination of all relevant subprocesses results in end-to-end processes, including all dependencies of results. Automated and manually conducted subprocesses are considered. Workflows of several organizational units are combined. The overall workflow automation flexibly connects the often still isolated solutions in the laboratory automation with single laboratory robots, workstations, and work benches. It also integrates manual activities. The end-to-end approach focuses not only on the classic experiments in synthesis or screening but also auxiliary processes such as the production and the storage of chemicals, culturing and maintenance of cells, preparatory activities, and the analyses of experiments. The combination of fully automated subprocesses and manual tasks improves the cost efficiency, considering the current situation in life science laboratories.
Furthermore, the connection of control flow and data flow in the same process model leads to a reduction of effort in the data transfer between the involved systems. The data flow, including the necessary data transformations, can be automated. Data generated in the process can be made available for other participating systems and people. In this way, automated processes can obtain and deliver information at just the right time from multiple sources and eliminate manual searches and paperwork. That avoids errors.
The inclusion of all human tasks in the controlled workflow increases the robustness and the quality of the processes. The control and the dedicated just-in-time IT support for manual subprocesses benefits the BPM-assisted workflow automation independent of the automation degree of used laboratory systems. The BPMS-based process-driven application initiates human activities of a current process instance with messages for users with appropriate roles (operating of devices, sample preparation, process monitoring, transport, and process documentation). Work lists and automatically checked time conditions support the coordination of parallel workflows. Especially useful for the human task support is the use of mobile computers and smart devices. Modern tablet computers have been proven to be useful for the documentation tasks using web-based LIMS. Furthermore, the necessary system functions, decision support, or additional information are provided. Complex IT systems will be easier and safer in their application because relevant subfunctions are called preselected by the workflow control. On mobile devices, this IT support is available anywhere and anytime.
Distributed Process Notations
The precondition for process automation and process management systems is an appropriate process notation that connects abstract operations that are logically correct and independent of the level of automation. The notation has to provide the execution of the modeled process using an information flow (e.g., for the transfer of process variables and data). The standardization of such notations is developed to different stages ( Fig. 1 ).
Typical automation structure of the laboratory automation and the different controlling languages.
The specificity of business process automation in life science applications is to ensure the process control in a particularly heterogeneous and highly variable environment, including manual, also highly variable, and sometimes complex interdisciplinary actions. This is exactly where dedicated executable process control systems (PCS) languages and manufacturing execution systems (MES)/laboratory execution systems (LES) solutions reach their intended limits. Systems of lower levels often have (instrument/vendor/domain) specific control languages. In integration scenarios, it is necessary to bundle the functionalities in black boxes. Common interfaces are required for controlling these bundled functions on a workflow level. Apart from standard solutions with a long life cycle, the approach of the interdisciplinary end-to-end workflow automation can be followed only by open, sufficiently universal process definition languages.
When BPMN exists, an established standardized graphical notation for the process modeling and automation pursues the objective to connect the different perspectives of business and domain experts, automation experts, and IT departments with one another.3,4 A BPMN model in the current version 2.0 (published in 2011) can be directly executed by a BPMN engine without translation of the business model into other languages for execution and systems integration (e.g., BPEL). The BPMN process engine coordinates all participants involved in the end-to-end process (humans, systems, and instruments) during the process enactment.
BPM Methods and Technologies
The authors purpose using methods and technologies of BPM as a new approach for integration and automation in laboratory automation. This enables especially the realization of end-to-end processes as a process-driven application in an effective manner. The use of model-driven applications in the life science laboratories ensures a basic variability and optimization of the automation degree. The model-based development leads to transparency and agility. The process is not hidden in the process execution code. The easy-to-read process model can be also used for monitoring and operations. Automated subprocesses and manual activities can be combined and may be replaced by each other at any time.
The implementation of such process-driven applications follows the typical BPM life cycle:
The leading application infrastructures that support the development and enactment of process-driven applications are business process management systems or BPM suites (BPMS). Such BPMS encapsulate a number of core capabilities, including the following:
The process execution engine
The model-driven development environment (BPMN process modeler)
Basic connectivity and connector library (interfaces to third-party applications)
User and role management and administration (portal)
Process management (portal)
Web interface, including task management with work lists (HTM client)
The process repository
In addition, there are simulation, monitoring, and reporting capabilities. With these functionalities, BPMS support all of the mentioned phases of the development and execution of process-driven applications. Today, there is a wide choice of tools with comfortable modeler and collaboration components supporting both business user and software developer in a uniform environment. A BPMS should not necessarily be used as a complete, closed system. Open frameworks are more developer-friendly—advantageous for complex integration requirements. Components such as modeler and engine can be integrated into their own applications as well. Appropriate application programming interfaces (APIs) are generally provided by BPMS vendors. BPMS based on the zero-code concept appear to be tempting. The business users and subject matter experts (SMEs) generate simple process applications without any IT specialists. But with increasing complexity of the process application and integration demands, such systems are restrictive for business users and software developers. The proper form of usage depends on specific environmental requirements in a given enterprise. In addition to the investment in a suitable BPM suite, further costs for software development are incurred.
Architecture of Process-Driven Applications
Distributed Applications for End-to-End Processes
Regarding the integration of the structured laboratory automation system, the end-to-end workflow automation connects distributed subprocesses horizontally of the workflow automation layer and vertically of the process control level, the device and instrument level, and, if necessary, also the intelligent field level (
Fig. 1
). A BPMN process model (
BPMN 2.0 within the context of distributed automation notations of laboratory automation.
Representing comparable systems, Figure 2 shows typical industry-specific, largely graphical process notations:
BPMS as a Central Platform for Generic Workflow Automation
In the proposed concept for an end-to-end workflow automation, BPMS is the central building block in the form of the integration platform based on BPMN 2.0 process models ( Fig. 3 ). The BPMS assists the standard-conform definition of interdisciplinary, interrelated business processes, including the data flow and interfaces to external services and third-party applications with a process modeler and additional tools and wizards for data modeling, interface definition, and creating of web forms. The process engine is an integral core part of the BPMS. The BPMS takes over the function of an execution-oriented integration platform. On one hand, the integration environment includes manual tasks that are specified and controlled with messages or other IT support options (human task communication). On the other hand, the basic model of the BPM-based workflow automation is based on a number of necessary service-system relationships; with them, the needed laboratory systems (PCS, information systems, etc.) are integrated into the workflow.
Representative architecture for the workflow automation in life science laboratories.
The presented solution for end-to-end workflow automation prefers a generic LIMS as a documentation platform and instance data store for workflow runs. Thus, with the BPMN 2.0–based workflow automation using a LIMS, a complete, overall process documentation can be generated and controlled. The favored approach of a combination of generic LIMS and BPMN 2.0 as an automation language offers the possibility of using the systems integration that already exists in the LIMS. This particular system position of LIMS results in the architecture illustrated in Figure 3 for the BPM-based laboratory automation. The adaptation effort relating to information technology (the service adapter drawn in Fig. 3 ) between the BPMS-driven workflow as a service consumer and more or less compatible components should be reduced in standards-based service-oriented architecture (SOA) environments.
Integration Methods
Regardless of the goal of workflow automation, industry-independent methods for integrating information systems with distributed services and data have been established. These include enterprise application integration (EAI) 5 and SOA. 6 SOA solves the functional and service-oriented systems integration via standard interfaces and achieves interoperability with decoupling of systems by orchestrating reusable SOA components. Web services are the most applied implementation of SOA. The integration of web service in BPMN models is an elementary capability of all BPMS. The enterprise service bus (ESB) provides a concrete SOA infrastructure of interoperable functions, services, and protocols. 7 In addition to the core task of creating connectivity, an ESB allows transforming data between applications and route messages. For the proposed standards-compliant BPM-based workflow automation direct service interfaces to specific information systems, EAI and ESB are crucial corresponding tools for the simplified implementation of interoperability and thus profitability.
Unfortunately, current control systems for laboratory devices and robots do not have or only seldom have appropriate interfaces, such as web service. An opening of such systems in this manner creates new opportunities for efficient workflows. The following example with a LIMS describes this in detail.
Data standards are also important preconditions to improve the efficiency in laboratory automation. Proprietary data formats are still usual. In such cases, the specific software is needed to reopen the result files. XML and XML-based standards such as AniML 8 are urgently required for simplifying the automated data exchange and the communication between scientists and customers. In this context, ESB is especially useful for handling proprietary data formats such as chromatograms. ESB can monitor the result directory for new files, which can be converted into commonly readable formats. Results can be extracted and stored in a database. In this way, they are available for all participants (scientists and systems) independent of the software that generates them.
Communication Channels
Providing suitable communication interfaces of external systems is a necessary prerequisite for integrating various applications of the heterogeneous laboratory system environment to control subprocesses or to handle data. The following integration strategies can be used to control PCS-assisted or instrument control systems (ICS)–assisted automation islands, transport steps, or predefined data processing as well. They can be distinguished from functional integration (e.g., remote procedure call, web service) and data integration (e.g., shared files or database, message-oriented middleware, ESB). The application domain focuses on functionalities to start a device-specific method, which is defined in a PCS or in an ICS, including the parameterization as well as the collection of results (measurements, reports, status, or location of result files) ( Figs. 4 and 5 ). Such a synchronous access is suitable for elementary, automated functional coupling with short execution times of the subprocesses.
Configuration of the web service connector of business process management system (BPMS) for synchronous communication with the middleware to start a process control system (PCS) method via web service call. The method name stored in the process variable “samiMethod” is a parameter of this web service. The used PCS is SAMI EX Workstation Software (Beckman Coulter, Brea, CA) to control the robot-assisted laboratory system for biological high-throughput screening.
Code for extraction of result value from XML structure of web service return value in Groovy. The web service returns the status of method start (values: successful, error: method not found, not ready). This code within the business process management systems (BPMS) connector extracts and maps the return value to the process variable.
Many applications of life science automation are divided into time-consuming subprocesses; for example, the execution of an automated screening experiment can require several hours or days. A direct connection or short-interval polling is problematic in view of this time requirement. But there are other efficient ways: the asynchronous communication (e.g., using message queuing or file sharing) leads to a loose coupling of the involved systems. Ordering and processing reactions are separated in time. The main advantage of the message queuing is the guaranteed delivery regardless of the current availability of the receiver. A message will be stored until the receiver picks up the message. The use of message queues to query the state of the current PCS method reduces the communication load on the part of the PCS considerably ( Fig. 6 ). The PCS sends every change in status to the message queue (e.g., Apache ActiveMQ [http://activemq.apache.org/]). Thus, it acts as a message publisher. The process-oriented application controlled by BPMS reads the message queue with a service activity (in the example “Status Query”). This activity uses a self-developed connector as an interface to Apache ActiveMQ. If the status string displays the end of the current PCS workflow, the process-oriented application can continue the process. The communication partner PCS and process-oriented application are independent in relation to time and the execution environment. The asynchronous communication affects the performance of the PCS minimally. This type of communication is very tolerant in terms of different technologies, programming languages, and operating systems. The replacement of an integrated IT system (ICS, CDS, PCS) is simplified by this decoupling. Besides text messages, other java types and objects can be exchanged via message queue.
Example of asynchronous communication using the self-developed MOMReceiver-connector within the business process management system (BPMS) for communication with the ActiveMQ message queue.
If a laboratory system does not provide any possibility for external access to functions or methods (e.g., by web service) and to transfer data, then integration is only possible when the service task is changed with a human task ( Fig. 7 ). In this case, an authorized person receives the request to execute a task with a specific laboratory device (e.g., perform measurements, use a method). All the necessary information (e.g., method name, experiment ID, parameterization) will be made available by the engine-controlled workflow. Usually, the user confirms the execution of the task with a status statement and/or results. This workflow is error prone; mix-ups cannot be excluded. The accompanying documents help to ensure the compliance with regulations.
Human tasks for starting the screening and confirming the method end.
The existence of interfaces for synchronous and asynchronous communication of laboratory systems is of tremendous importance for efficient process control and data exchange, resulting in smoothed and simplified workflows, reduction of execution times, error avoidance, and reduction of the load of staff.
The favored approach for BPMS-LIMS coupling has special requirements for the information system, which are explained in the next section using the example of a specific LIMS.
LIMS as a Generic Information Management System for Process-Driven Applications
LIMS as Global Documentation Systems
LIMS as IT-assisted documentation systems and result storage systems have been established not only for analytical subprocesses. Configurability, web platforms, SOA features, APIs, and others identify the progress of the recent years. 9 Nevertheless, LIMS are often still used as stand-alone solutions. System networks commonly focus on the automated data acquisition from laboratory equipment (e.g., analytical results). The extent of coverage of process documentation and thus also the extent of the master data management within LIMS has increased dramatically in the past 10 years. The data and information consistency in the laboratory have benefited from this.
The completed integration or system coupling between LIMS and electronic laboratory notebooks (ELN) also follows the primary objective to reduce data redundancy and synchronization problems. In addition, it optimizes the management of structured and unstructured information and benefits of information sharing in collaborative scenarios. However, ELN are also the result of a lack of integration of existing islands of automation. Due to the lack of automated detailed communication between the systems, unstructured information often has to be exchanged via ELN. Compared with ELN and other information systems, LIMS assumes the key function in the workflow documentation of the wide laboratory practice. 10 However, a strong overlap of LIMS, ELN, and scientific data management systems (SDMS) exists today, which can be solved only by systems integration.
At the Center for Life Science Automation (celisca) at the University of Rostock, a generic approach for hierarchical process documentation has been developed in recent years under the short name of openLIMS. This application is validated for the scientific disciplines of chemistry, 11 biology, 12 and medicine. 13 The validation process included the documentation of numerous semiautomated projects from different research areas.
The application openLIMS merges data and information pools, which are often distributed (ELN, master data management, chemical inventory management, process execution data, experiment result data, etc.). Thus, it intervenes in the domain of enterprise resource planning (ERP) and other solutions. Because the openLIMS is already available as a web platform for intranets, different components can be easily used by web service for execution of the activities.
Highly variable research and development (R&D) processes of life science automation have a different flat to deep process hierarchy that requires any detailed process documentation. For the process documentation of these processes, an open, database-driven process documentation system with a runtime extensible database model is required.
An Open Parameter System for LIMS
A core of this open-process description is an adaptable parameter system that is generated on the basis of an adequate data-type system for describing process parameters. In addition to simple status and description parameters, complex data structures, such as multidimensional time series, images, or chemical structures and reaction relations, are used. Furthermore, any process parameters with validation properties (e.g., discrete and continuous definitions of validity) are definable. This establishes a comprehensive parameter-type system for both process descriptions and master data. In the openLIMS, a parameter-type system shown in Figure 8 have proven to be sufficient for the above-mentioned target areas of life science automation (chemistry, biology, medicine) in the past years.
Current parameter-type system for end-to-end process documentation.
The meaning and effects of the presented parameter type model can be summarized in the following 10 facts:
The parameter system is the base of generic and integrated (in terms of EAI) information management for laboratory processes with any structures, complexity, and end-to-end ranges.
The generable parameter-type system is complete for the description of any activities with any complexity in black boxes. It is also suitable for the description of all data objects and message structures in end-to-end-workflows. These include ingoing and outgoing conditions of activities, any process states, events, decision parameters for control structures of workflow execution, documentation of dialogue data and process control variables, measured variables and derived result variables, and support of the smooth transition to the ELN (e.g., for recording unstructured information).
The generable parameter system covers potentially all obligations to report and document about process steps in compliance with guidelines of good laboratory practice (GxP).
Elementary parameters can be combined to get any parameter structures.
Parameters can be used to define time series. Data can be captured synchronously and asynchronously.
Chemical structures and reaction parameters are managed and stored in standardized codes that allow the searching of chemical substructures.
The multimedia recording of information is supported by parameter types for images and voice recording.
New classes of information, including classes for master data, can be added at runtime using all previously defined parameters (description parameter of the new class of information). Then they can be used again as complex discrete parameters for data sets for process documentation. In accordance with the terminology of database modeling, these parameters are denoted as a relation-type parameter. The thus achieved flexibility is consistent with the specific needs of life science research and development (operating and adding cell properties, sublibraries of compounds, material properties, differentiated resource management, data objects for interfaces, etc.).
The parameter system is applicable in all required hierarchy levels of process mapping. Both the parameter system as well as its links is extensible.
For the capture and application of parameters, corresponding web-based dialog components are available within the LIMS.
The generated parameter system is based on the needs of the integrated, any detailed process recording. In particular, complex parameters consider all characteristics of measurement technologies, including the experimental, producing, or testing life science applications. The data system is sufficiently canonical for the life science automation. It can parameterize the whole process automation hierarchy from the workflow level to the level of the sensor-actuator nodes (e.g., n:m-relationships in an entity relationship model). The achievable complexity of parameters can be illustrated by the example of time series; their parameter structure is composed of a mix of validated parameters, simple parameters, and relation-type parameters (i.e., records from a total amount such as of chemical inventory or compound libraries). This parameter complexity is very real for the observation of material or medical workflows.
Process Documentation within LIMS
The process recording within openLIMS using the descripted open parameter-type system is shared by seven hierarchy levels, called process description levels (PDLs). Table 1 establishes a relationship between the different PDLs, the process documentation, the general workflow structure, and the structured laboratory automation from a practical point of view. Each mapping level can be documented with the whole custom-tailored parameter system. These parameters form any attributes of the PDL.
Application of the Parameter System for the Hierarchical Process Mapping.
BPM, business process management; BPMN, business process model and notation; BPMS, business process management system; PCS, process control system; PDL, process description level.
A focus is the labeling of process steps, which correlate with the atomic activities in workflow models. The typical mapping level for sensors/actuators, devices and instruments, and process control systems of complex laboratory robots is an interesting reference to laboratory automation. This shows the differentiated mapping compatibility between LIMS and each represented automated/semiautomated subprocess ( Table 1 , column 4). This juxtaposition is the basis of the online communication between a generic LIMS and an arbitrary distributed system environment in the laboratory.
The interface adaptation of exchange messages mainly refers to the specific process description levels described in Table 1 . The overall workflow automation approach should be adequately documented up to test series (i.e., PDL 3–7). The LIMS as an integrated information management solution can also map the organizational levels of documentation—in this example, project and study management, which is typical in R&D. These description levels are generally outside of the needs of model-based workflow automation.
Application Example for BPMN-Based Workflow Automation
The following laboratory application example illustrates the presented concept for the process-driven laboratory automation and points out the integration of the LIMS as a documentation platform.
For the BPM-based end-to-end workflow automation, LIMS fulfills four requirements:
First, the LIMS acts as a generic platform for recording data of process instances. Each business process model acts as a blueprint for a set of business process instances. The model represents the common workflow. The instances differ in the runtime data.
Second, the LIMS provides extensive interaction components for “human tasks” (e.g., data management and visualizations).
Third, the LIMS supports automated access to distributed process data within the automation system by specific services if the data acquisition is not realized by service tasks in the BPMN process.
Fourth, the LIMS provides an integration platform. The integration refers to additional functions of LIMS (EAI) and interfaces to other information systems on the workflow level (e.g., master data management, document management, chemical inventory management, or data processing).
The following example shows new interaction concepts for setup, configuration, and execution of laboratory workflows provided by the BPMN-based workflow automation. The example LIMS is very suitable to show integration details because the used LIMS capabilities are very manifold. The communication can be performed synchronously for information research or asynchronously for long subprocesses such complex data processing. The used openLIMS offers many functions such as web service. The integration principle can be transferred to any other automation and information system used within laboratory workflows.
The Process
The selected process describes validation experiments in the context of the development of methods for the analysis of chiral compounds such as amino acids based on mass spectrometry. The process is characterized by short analysis times compared with common analysis techniques in the determination of enantiomers. This enables the application with time-efficient, high-throughput screening procedures. 14 Steps in sample preparation, dosage, and evaluation of the experiment build the frame around the instrument-level automation of the measurement processes using the instrument control and data analysis system (MassHunter; Agilent Technologies, Böblingen, Germany). To meet the requirements of high-throughput systems, it is necessary to combine sample preparation, analysis, and data evaluation in a versatile and easily adaptive processing system with a minimum of manual work. The solution can be analyzed as part of the validation methods used to evaluate the precision of interday (repeated measurements on different days), intraday (repeated measurements within a day), and interoperator experiments (repetitions by different operators). These experiments will be repeated whenever the suitability of the method has to be checked for another class of materials (e.g., amino alcohols, amino acid esters or natural chiral compounds). Intraday and interday experiments differ only in the waiting time between two experiments. In the interoperator variant, the actor assignment iterates over a user list. This iteration can be implemented very comfortably by the resource allocation of the BPMS modeler. For these reasons, the proposed model-driven workflow automation is extremely useful for this application. The opportunities for integrated documentation benefit the method validation process. The automated workflow ensures the repeatability under the same (limited) conditions. The accompanying automated workflow documentation leads to the reproducibility, traceability, and transparency of the processes and their results.
The Process Model
Figure 9 shows the process model of the described workflow in BPMN 2.0 syntax. There are two process participants who are also provided “roles”: the scientist (chemist) as investigator and the laboratory assistants (staff). The role includes a group of persons that is represented in the process model by the lanes. During runtime, an activity instance is normally offered to all people available who are members of the role and thus capable of performing the task.
The process model of the example application. Green activities represent the LIMS–related activities mentioned in the text for demonstrating the integration of the LIMS.
LIMS Configuration for Novel Experiments
In the presented reference system openLIMS, the definition of parameters and templates for the process-driven workflow definition is done in the phase of process analysis before starting novel experiments. From the methodological point of view, the consistency of the description between the parameter library and the process documentation repository is very important. The respective BPMN process model, which reflects the overall workflow on the level of test series, is a series of activities connected by the control flow. The extension of the model by resource allocation and the treatment of the data and information flow lead to the executable process model. The LIMS must be capable of documenting the data flow in compliance with the process requirement analysis using consistent syntax and semantics. The data flow allows reconstructing the control flow later. The LIMS is to be configured corresponding with the process model within BPMS. These configuration steps include the below-mentioned parameter system and the hierarchical documentation templates, which correspond preferably to the message structures for the exchange of information between BPMS and LIMS. With these preparations, BPMS-controlled experiments can be performed and documented in runtime.
Planning a New Experiment Run
The investigator is already supported by the workflow control in the experiment planning. The used LIMS provides a feature for an automated template-based setup of test documentations via web service. This subprocess template will be parameterized by the number of repetitions of the upcoming validation experiments. The BPMS initiates the documentation of the current workflow instance within LIMS via service calls during the process execution. The service interface covers the communication and the required data transformation. The activity, “Experiment Design and Documentation within LIMS,” also answers the following question: Which compounds are to be tested with which method on which instrument? The scientist finds the order for that in the worklist within the human task management of the BPMS client. Such a worklist exists for each user and publishes the orders for each manually conducted step. The client is also available on mobile devices. As a result, employees are immediately notified of pending tasks. Together with these task requests, functions of involved information systems required in the respective process step are provided via URL calls (selection of test series in LIMS for information about experiment setup, help desk for master data information, remote desktop of ICS, knowledge base, etc.). For the compound management and chemical inventory, LIMS functionalities are used ( Fig. 10 ). Such provision of selected, activity-related software components is an important form of IT support in process-driven applications. The manual navigation to the current experiment description within the complex software LIMS is canceled, and thus an error-prone time-consuming step is removed. This just-in-time method of correct preselection of functions and information results in noticeable reliability and time savings. This activity can be expanded with an automated check of the inventory availability for required chemicals via synchronous web service call (as shown in Fig. 4 ).
Information technology support of workflow control by providing of selected activity-related components of the laboratory information management system (LIMS).
During the Experiment Run
After finishing the experiment design, planning the run can be started. The following sample preparation steps are the responsibility of laboratory assistants. The workflow control sends notifications to worklists of all laboratory assistants (task 2). The order message includes the required information about the compounds to be supplied (task 3). The notification with the information is sent to worklists of all employees with the role “lab staff.” An arbitrary laboratory technician takes the order and executes it (task 4). The current list of compounds is requested from LIMS via web service call and sent per email to this operator ( Fig. 11 ). On one hand, the implemented workflow automation replaces the previous time management, which often is controlled by a kitchen timer. On the other hand, additional opportunities for the effort-reduced, automated documentation of such manually performed activities are opened. This results in fewer gaps within the process documentation and increases the traceability of processes and results. The troubleshooting can be simplified.
Information request via web service call and following sending of this information via email.
In the following workflow activity (task 5), only the user, who has taken the supply task (task 2), receives a request to confirm the execution and comment on the results ( Fig. 12 ). For all other members of the role “lab staff,” this request is not relevant. The BPMS “knows” who has taken which task. Based on this knowledge, it can assign the confirmation request to the actual owner of the compound-supply-task. The supply of samples is automatically logged in the LIMS with timestamps and the name of the operator, immediately after the execution confirmation by the operator (task 6). The addition of the process documentation within LIMS can be performed by the process application via web service interface of the used LIMS ( Fig. 12 ). It is automatically logged in the LIMS, which compounds are supplied at that time. The process-related human task interaction leads to the expected significant relief of laboratory staff who are involved in multiple, simultaneously running processes.
Logging of human tasks within the laboratory information management system (LIMS) as documentation platform.
Owing to the lack of appropriate interfaces, a direct online communication with the MassHunter software for an automated start of the analytical method is not possible. The MassHunter method has to be parameterized and initiated manually, as described in Figure 7 . After the measurement, the raw data of the daily measurement are imported automatically by an in-house developed, MS Excel–based evaluation tool to determine the mean values of the replicates, standard deviations, and coefficients of variation of the enantiomeric excess.
After the Experiment Run
With a positive result of the plausibility test executed by the senior chemist, the files with derived data are copied automatically to a central backup server (file moving using the tool Robocopy). The next step of the workflow automation integrates an ESB job, which monitors the report directory and processes incoming files (asynchronous file-sharing interface). The ESB subprocess selects the interesting data from the result file of the daily experiment and distributes them to various target locations: first in the database of the LIMS and second also in another Excel template for the complete experiment evaluation. Until now, this task had been performed by manual copying. Now the time-consuming, error-prone manual data capturing and copying are eliminated by an automated BPMS-controlled workflow. ESB is predestinated for routing of data to several destinations integrating filtering and transformations. The use of the described process in all causes of method validation results in identical process flow, which increases plausibility and reproducibility, especially in method development and validation.
Partial powerful service tasks in application projects of life sciences include automated pre-and postprocessing, such as test calculations, raw data processing, or statistical model calculations to experimental behavior. This functionality is also integrated in openLIMS 15 and can be used via web service interfaces. The integrated third-party systems are commercial statistic tools or common spreadsheets. Advanced functionalities for automated data acquisition extend the possible applications of LIMS related to service providing for the workflow automation of the BPMS. The detailed description of this goes beyond the scope of this article.
Evaluation Results Regarding the LIMS-BPMS Coupling
In summary, it can be stated that it is possible to fulfill the requirements of the user interaction as well as an automated overall process documentation using BPMS in life sciences only with great development effort. But if a generic LIMS is used as an integrated documentation component, it offers improvements for an efficient development in combination with BPMS.
The presented complex application example points out the typical interplay between the BPMS-based workflow automation and a domain-specific information system. This leads to a workflow-driven documentation of process instance data in addition to the automation effect for the overall workflow. The personnel will be relieved of documentation tasks, data transfers, and transformations. With regard to the rules of GxP but also for systematic research and development, the BPM approach offers effective contributions to improved quality management.
The focused BPM approach aims for the functional synergy of LIMS and BPMS in a generic overall solution that also enables the IT support of LIMS as required, synchronized with the execution of process instances. IT support here means providing selected, activity-related software components such as the compound selection in the example. A representative selection of such support options and user interfaces for BPM applications in life science automation is shown in
Figure 13
. This selection pointed out the diversity of such support options. Based on the model for workflow control with relevant activities (
Representative examples of support of laboratory information management system (LIMS) for process-driven applications.
An adequate canonical data-type system and the corresponding service-oriented interaction components to manage and use open-process parameters in an open-process mapping hierarchy form the core of LIMS requirements for a successful BPM approach to communication.
Moreover, existent LIMS services to other information systems of structured laboratory automation or to automated information processing simplify the implementation of a BPMS solution. The LIMS acts as middleware and in terms of a second integration platform. Many LIMS vendors provide numerous system interfaces, particularly for analytical measurement systems. This leads to a considerable simplification of the system architecture for the BPM-based workflow automation.
Table 2 summarizes the most important tasks of a LIMS in an application combined with BPMS. The master data acquisition and management are usually outside of BPMS-controlled workflow directly in the respective information system (e.g., in ERPs, here in the LIMS). However, there is always the possibility of introducing such activities of master data management directly into the process model.
Application Coupling openLIMS-BPMS at a Glance.
BPMS, business process management system; ELN, electronic laboratory notebook; LIMS, laboratory information management system; PDL, process description level.
Discussion
The process modeling using the graphical notation standard BPMN 2.0 meets the requirements of a high-process transparency for both robust end-to-end workflow controls and for knowledge management. All participants in research and in customer order processing benefit from the high-level standard-based and process-driven IT applications. The BPM-driven laboratory automation combines both manual and automated activities (respectively, subprocesses). End-to-end process models promote understanding of the overall relationship and dependencies between some steps as well as overcome boundaries.
Benefits for Scientists
Flexible processes: The graphical process notation not only results in transparent process models but also makes the process models flexible. Scientists are capable of adapting the process model by changing activities or parameters. If process repositories with implemented subprocess models exist, then scientists can compose new process models with building blocks from the repository. In the example application, the sample preparation is conducted manually or automated depending on the used chemicals. The adaption of the process model is very easy if there is an implemented building block for the automated variant in the process repository. The scientist exchanges the task and adapts the parameter without support of the IT team.
Workflow reliability: The process-driven application ensures that some process instances are performed in the same way—even if the time offset between two reruns is longer or the performers are different persons. The equivalent documentation of all process instances allows the information retrieval and data analysis with automated procedures.
Data and knowledge availability: In the field of complex life science applications, the combination of graphic, arbitrarily detailed, directly executable process models as well as a link between the process documentation and the process model allows a quality of know-how capturing and sharing that has not been not achieved until now. The close integration of recording information system and workflow automation leads to less redundant data storage, because the resulting data will be provided to the target system immediately and in the required form. Alternatively, the data are stored uniformly in the central information system. Measurement results are available and comparable in the context of the integrated workflow definition. The extended workflow documentation with logging of manual tasks allows faster detection of the causes of errors located within the workflow (storage conditions, waiting times, etc.).
Benefits for Customers in Internal and External Business Relationships
Customers obtain detailed reproducible information about how measurements and results are generated. All impact factors of a result are visible by using an end-to-end BPMN process model. The customer can pick up the process execution models of cooperation partners and can add them to the process repository, with or without process execution data. This is an important step to improve compliance. Otherwise, a customer can deliver a process model as a service request, and a service provider can embed this process model in his or her own workflow routines to realize the collaborative job. Thus, by using the BPMN 2.0 automation approach, an important instrument for quality insurance and knowledge exchange results.
Benefits for Operators
Organizational policies and procedures are automated in guided workflows. That saves paper and time. Single tasks can simply be handed over to other operators. Tedious manual documentation tasks are relieved by the extensively automated documentation. The automation of data flow and the integration of manual tasks into the timed workflow control avoid errors.
In the case of BPMS-driven applications, the advantages of mobile information systems are particularly in evidence. Both the process-driven information provision and the information acquisition may be independent of the current location. By many individual effects, workflow automation secures considerable relief for the laboratory staff, which often acts simultaneously in workflow instances in spatially distributed environments. BPMS improve the just-in-time support of involved IT systems.
Benefits for IT and the Automation Engineering Team
The process models using BPMN are understandable for all stakeholders (SMEs, IT, automation engineers, and management). With the unique process model, there is a joint development basis. The model-driven development reduces the development process for new automated laboratory applications. A comparative study about implementation with object-oriented programming languages attested to the use of a BPMS with five to seven times higher productivity. 16 The exchanges of external systems or interface adaptions have effects only on limited areas. Because of the extensive separation of process and interface implementation, the process model does not have to be changed in the case of adaptions. This goal can be achieved, for example, by using an enterprise service bus for data routing and transformations.
Dealing with one unified, easy-to-use (that can be used by both SME and IT) platform for development and execution of process models is a tremendous benefit.
The LIMS as a well-established middleware can simplify the development process by acting as a server for dialogue components and a service-oriented platform for automation systems. For the expected future event that sub-workflows as part of LIMS are automated (e.g., with focus on recording of subprocesses), the end-to-end workflow automation can use these as already available subprocesses equivalent to PCS methods for islands of automation. The numerous components for manual task support within advanced LIMS argue for the proposed combination approach for laboratory automation. Solutions for automated service tasks with the automation systems as a data source belong to these components, too.
Footnotes
Declaration of Conflicting Interests
The authors declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The authors disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: The German Research Association (DFG) is gratefully acknowledged for funding this project (HO 4566/1-1). The German Federal Ministry of Education and Research (BMBF) and the Ministry of Education, Science and Culture of the State Mecklenburg-Vorpommern provided financial support to celisca.