The discovery of new therapeutic molecule has become a highly demanding endeavour. The main goal is to find an effective molecule, i.e. one that address a particular disease. On this path many conditions need to be met. A critical one is to ensure the safety of the molecule, meaning that it only targets the disease and nothing more. Next, while having ensured safety and effectiveness, another question that arises is the suitability for production, i.e. is it even possible to produce the molecule consistently and at scale over the many years the medicine will be available on the market? This is especially challenging for biologics, i.e. large therapeutic molecules produced by living cells. Looking at the software landscape in pharma research we are confronted with a highly heterogeneous view, involving a broad combinations of different software systems with various interfacing possibilities. Molecules are tracked in registration systems, lab information management systems or electronic lab notebooks store process data. Requests between labs are handled by requesting systems, robotic systems (liquid handlers, analytics) produce large data and we can’t ignore the amount of spreadsheets used to document or calculate. While faced with complex questions, researchers have developed a series of individual methods that, on their own, answer or help with a small part of the questions above. The true value comes by automating the combination of these methods into end-to-end processes that answer the full research question. Thus it is more than fitting to use business process modelling not only to describe the research process, but to also execute it. In this presentation we show the use of business process modelling to map and drive research processes stretching over researcher decision points, backend systems and robots. In particular, our current robot integration is to treat robots as external systems where the orchestration engine configures, monitors and collects results while the user is still fully in charge of loading and triggering an actual run. Unlike fully automated setups, a research environment demands flexibility as processes and their branches change. Even so, we show by using executable business processes in the pharma industry research, we increase throughput, transparency, standardization and time-to-results .

1. Pharma Research Automation
Daniel Butnaru
13th September 2019

2. What is the problem?

4. Many leads but only
few successes

5. New Challenges for Research & Development
Disruptors
▶ the death of the blockbuster drug (20% return increase for doubled investment)
▶ new drugs and working methods
▶ commercial pressure and time to market

6. New Challenges for Research & Development
Disruptors
▶ the death of the blockbuster drug (20% return increase for doubled investment)
▶ new drugs and working methods
▶ commercial pressure and time to market
Flexibility but also throughput
▶ labs must allow rapid configuration changes based on scientific needs
▶ R&D process needs to increase efficiency by increasing throughput

7. Is this the lab of the
future?

8. Or maybe this is the
lab of the future?

9. Zooming in: Drug Discovery
The goal is to find a molecule which has affinity to a certain target

10. Zooming in: Lead Identification
Find compounds that show desired biological and pharmacological activity

11. Zooming in: Assays
An assay is an investigative procedure for assessing various properties of leads

12. A Typical Assay Flow
configuration robot
execution
result processing

13. Pharma Research Application Landscape
Assays rely on base capabilities and internal core systems

14. Pharma Research Application Landscape
Assays rely on base capabilities and internal core systems

15. Design and Explicitly Map Processes
The automation landscape consists of API-enabled individual systems

16. Design and Explicitly Map Processes
A assay involves calling different systems in a particular order

17. Design and Explicitly Map Processes
Assays as executable BPMN processes

18. Reconfigure on Demand
A process is reconfigured as the process level with systems left unchanged

19. Build a Collection of Data Processes
Map all assays to digital workflows

20. Architecture

21. Orchestration and Overall Architecture
Camunda orchestrates external tasks with data exchange over an object store

22. Devices

23. Bruker Maxis [Mass Spetrometer]
Biomek i7 [liquid handler]
Thermo Scientific [Chromatograph]
Biomek i5 [liquid handler]

24. Automation Layers for Research
Automation is hierarchical with decreasing complexity towards the top

25. Device Connectivity
A device is wrapped at different levels

26. Device Connectivity
A connector links the robot to the orchestrator

27. Device Connectivity
Data IO is a dedicated task at connector level

28. Robot BPMN
Configure, monitor execution and collect results

29. Data Wrangling

30. Data Transformation Broker
Custom glue code maps task queue to backend systems

31. Modeling of Data Transformations
Inputs/Outputs of a service task configure the transformation type and its arguments

32. Data Exchange
Object store manages data while camunda passes data references between tasks

33. Process Modeling as a Platform

34. BPMN and the Organization
Considering the organization structure is critical for evolutionary process modeling
department 1
department 2
department 3

35. BPMN as a Internal Platform
Users develop, publish and maintain own process definitions and transformations

36. BPMN as a Internal Platform
Users develop, publish and maintain own process definitions and transformations

37. Summary
Most pharma research activities consist of a sequence of assays
Assays are modelled as executable BPMN processes
All non-human tasks are external tasks picked up by brokers
Only a shallow integration of devices is done at business process level
Opening modeling to the users allows us to scale and increase BPMN coverage of assays

38. Doing now what patients need next