As scientists working in pre-clinical drug development, we are constantly balancing the need for rigorous, mechanistic modeling with the realities of fast-moving project timelines. Physiologically based pharmacokinetic (PBPK) modeling has become a core tool for informing decisions throughout the drug development process, and is a rich source of scientific insight into a drug’s behavior. However, as many of us can attest, the process of actually building the models can be time consuming and is often repetitive.
I frequently find myself spending more time managing data than interpreting it: organizing measured values and profiles, setting up runs, exporting results, generating plots, compiling reports…and then repeating this process across multiple scenarios. These are all necessary steps, but when done manually, they can quickly become bottlenecks.
Manual Workflows: Necessary but Inefficient
The traditional way of working in GastroPlus—and indeed, in every PBPK platform—has always involved a lot of clicking. Even straightforward tasks—adjusting compound parameters, creating physiology and dosing schedules, loading observed data profiles—require repeated manual effort. That’s fine for a few runs, but once you have dozens of compounds or multiple populations, the process feels like it doesn’t scale well. The problem, however, extends beyond mere inefficiency, as manual entry carries the risk of mistakes and typos that can creep into projects unnoticed, which adds to the QA and QC burden at the tail end of every project. And perhaps most importantly, every hour spent on these steps is an hour not spent on what really matters: analyzing results and applying insights to key development decisions.
A Structured, Scripted Approach: Introducing GPXOrchestrator
That’s where Orchestrator comes in. Released with GastroPlusX.2, Orchestrator—which comes with dedicated packages for R and Python—adds a REST API layer on top of the GastroPlus calculation engine. In practice, this means you can write a script that tells GastroPlus to open a project, add data, run simulations, and return and plot results.
Once a workflow is scripted, it becomes reproducible, scalable, and extensible. A process that might normally require hours of manual interaction can now be launched with a single command, run unattended, and deliver structured outputs ready for review.
I like to think of it this way: GastroPlus has always been a powerful modeling environment, but now it’s also machine-readable. It’s digestible by computers, which makes it possible to connect, extend, and automate in ways that weren’t available before.
Why This Matters: Reproducibility, Efficiency, Flexibility
Automation isn’t just about saving time—it’s about doing better science. With Orchestrator, every workflow is explicitly documented in code, which means it’s traceable, shareable, and easy to re-run. This improves reproducibility both within and across projects.
It also creates room for flexibility. Because workflows can be run inside R or Python, you can build advanced plots with ggplot2 or matplotlib, integrate custom PK calculations, or export results directly into other systems, such as internal databases or machine learning pipelines.
These points may sound like ‘nice-to-haves,’ but in practice they make GastroPlus workflows more adaptable than ever, allowing the modeling process to be tailored to the specific goals of each project.
Example Use Cases
When working on an early-stage discovery project, we typically have a library of candidate structures, from which I want to identify a few lead compounds. To accomplish this, I wrote an Orchestrator script that imports them via ADMET Predictor®, queries our database to automatically attach any corresponding observed data, and queues up the simulations. When the runs complete, the script retrieves PK summaries and concentration–time series, assembles tidy tables, and produces a few standard plots. I like to have it then rank compounds by a handful of PK parameters and drop a quick panel plot into our team notes. All of this happens automatically; my job is to look at the results and decide which compounds are the best candidates for a closer look.
For later-stage projects, we instead might want to look at how a single compound behaves across a variety of populations. The population simulation run mode in GastroPlus is already a great way to simulate this, but if I want to manually dig into which attributes are responsible for inter-population differences in steady-state concentrations across multiple doses, that takes time…a lot of time. Instead, I wrote a script that executes the manually created population simulations and conducts analysis.
First, I will take the baseline simulation and create a population simulation for each set of demographics, adults in the age range of 30-40 years and pediatrics in the age range of 8-12 years, for example. Orchestrator will then run those simulations, gather the results, and extract the Cp-time profile for each subject following the final dose. With the results at steady-state, it then calculates the partial AUC, Vss, and concentration window. These are then grouped, and cross-referenced with the sampled population parameters, identifying any key physiological or pharmacokinetic properties that appear to drive the inter- and intra-population differences. While this script does take some time to run, it runs in the background, allowing me to attend to other tasks—and when I do come back to it, I can dive right into interpreting the results.
Closing Thoughts
For me, the real value of automation via Orchestrator is that it takes the friction out of PBPK workflows. It doesn’t replace the science, it lets me spend more time on the science. By automating the repetitive steps, I can focus on interpreting results, exploring permutations, and contributing my expertise where it matters most.
This is just the beginning, and I’m excited to see how Orchestrator will continue to evolve. If you’re ready to move past repetitive workflows and embrace a more scalable approach to PBPK modeling, GastroPlus X.2 with Orchestrator is the place to start.