How Zimmer Biomet accelerated in silico clinical trials more than 1,000x with AWS

In this post, we share how Zimmer Biomet, working with AWS, Invisibl Cloud, Ansys (part of Synopsys), and Dassault Systèmes, changed what a medical device engineering team can accomplish by using AWS to scale the process of computational simulations. The team started from a previous in silico clinical trial (a clinical trial done on the computer using virtual, realistic patient models) for a shoulder replacement implant. That study, conducted on-premises, took over 3 months to complete 1,042 successful simulations of virtual surgeries. The team then ran a scaled version of the study, with a goal of completing 30,000 successful simulations, start to finish, in under 24 hours on AWS. The run actually delivered 46,662 successful simulations in a single day, about 45 times the original study.

We walk through the seven-step computation pipeline behind a single virtual surgery simulation, why that pipeline resisted scaling on-premises, and the orchestration system Invisibl Cloud built on AWS to run thousands of simulations concurrently. We also share what we learned about capacity, licensing, and simulation solver failure handling along the way.

Figure 1 shows the implant system that the study evaluated: an anatomic total shoulder arthroplasty with a glenoid component and a humeral stem.

Figure 1: An anatomic total shoulder arthroplasty implant system. Every implant system has to be tested with simulations for a wide range of patient anatomy, bone quality, and surgical variability. (Credits: Zimmer Biomet)

Why in silico clinical trials matter

Bringing a new medical device to patients takes time. A traditional clinical trial for a medical device—a shoulder or knee implant, a heart valve, a spinal fusion device—typically runs 3–10 years through patient enrollment, multi-year follow-up time, and regulatory review. During those years, patients who could have benefited from a better device might not have access to it.

Traditional clinical trials typically consist of a small cohort. Orthopedic trials usually enroll around 100 patients (per group), sized to detect a primary endpoint with statistical rigor. That is entirely appropriate for the primary endpoint, but it exposes an issue: Many influence factors are obscured by patient and surgical variabilities, and complications that occur at low single-digit rates are difficult to detect with small cohorts. Understanding the tails—to detect any influence of (rare) anatomy, bone quality, surgical placement variability, and surgical decisions—requires case volumes that a small cohort study, or often even national registry data, can’t readily supply.

In silico clinical trials address both problems and might complement conventional clinical trials. Engineers build a large virtual patient population from real patient data, such as bone models reconstructed from CT scans, and simulate the surgery and its mechanical consequences on each virtual patient using simulation techniques such as finite element analysis (FEA). Because the cohort is virtual, it can be built deliberately to span a broad parameter space, including the extremes, and the same patient model can be analyzed with multiple treatment options or surgical parameters, allowing for a direct comparison of different surgeries in the exact same patient, which is impossible in real patients.

With computational resources typically available on-premises, a multi-year clinical trial can be simulated in months. A study of about a thousand finite element simulations, like the one described in the next section, previously took Zimmer Biomet over 3 months on-premises. That is faster than a clinical trial, but still too slow for routine use in design iteration and optimization. This study set out to remove that limit and run 30 times as many simulations within a single day on AWS.

The starting point: A completed shoulder arthroplasty trial

The project started from an already completed and validated in silico clinical trial for a total shoulder arthroplasty implant, done by Zimmer Biomet on its on-premises computers. Its researchers published the methodology in npj Digital Medicine and the validation of the primary stability model, against benchtop and clinical data, in Annals of Biomedical Engineering, and of the stress-shielding model in IEEE Transactions on Biomedical Engineering. The trial covered 45 virtual patient anatomies with up to 12 virtual surgical interventions each, 521 virtual surgeries in total. Each surgery was analyzed for two clinical failure modes, humeral stem loosening and stress shielding, and each of those simulations evaluated three load cases. The 1,042 successful simulations took about 3 months of wall-clock time to run.

Starting with a completed, validated, on-premises in silico clinical trial gave the team a correctness target: whatever the cloud implementation produced had to match the original results. Secondly, it also gave an on-premises throughput performance baseline, measured on a real study.

The goal we set was deliberately aggressive on both axes at the same time:

• Expand the cohort by 30 times, from roughly 1,000 simulations to 30,000
• Compress the wall-clock time from 3 months to a single 24-hour window

The target is sized against clinical practice. Fifteen thousand virtual surgeries, each analyzed for both failure modes, is roughly 1.5 times the number of total shoulder arthroplasties performed each year in the United Kingdom, or in Australia, according to the UK National Joint Registry and the Australian Orthopaedic Association National Joint Replacement Registry. In other words, a single day of computation can produce clinical outcome data on more shoulder replacements than either country performs in a year and a half.

What one virtual surgery simulation actually involves

The reason this pipeline is hard to scale becomes obvious when we look at what a single simulation requires. It contains seven sequential steps across three different software packages, two operating systems, and wildly different resource profiles, which were automatically executed (orchestrated by a validated pipeline written in Python). The following figure illustrates these steps.

Figure 2: The seven steps required for a single virtual shoulder surgery simulation, with measured runtimes from the on-premises baseline

A few things stand out from Figure 2:

• Step 1 is a virtual surgery – Before any finite element analysis happens, the implant has to be virtually implanted into a virtual patient’s anatomy—positioned, oriented, and seated the way a surgeon would place it. This is where patient-to-patient and surgeon-to-surgeon variation enters the study, and it accounts for approximately 21 percent of the total runtime.
• The solve is only half the job – Step 6, solving the finite element analysis, is 54.5 percent of the total runtime and is the only step that can be partitioned over multiple compute cores and where increasing the number of cores reduced the solve time (at the cost of additional license tokens). The other six steps together are 45 percent of the total runtime and are all single-threaded, where multiple cores could be used for parallelization but not for runtime reduction. Therefore, a traditional approach that treats the whole pipeline as a single high-performance computing (HPC) job and sizes the cluster for the solving step wastes most of its cores most of the time.
• It spanned two operating systems – Steps 1–5 and Step 7 run on Windows, whereas the FEA solve in Step 6 can run on Windows or Linux. The orchestration layer has to pass work back and forth across that boundary tens of thousands of times without losing track of it.
• Every step consumes commercial licenses – Ansys, Abaqus, and ZiBRA (Zimmer Biomet in-house tool) all require licenses. Running thousands of simulations concurrently means the license pool can become the binding constraint before compute does. For this project, Zimmer Biomet produced a license-free build of ZiBRA to run on AWS, and Synopsys and Dassault Systèmes supplied the Ansys and Abaqus licenses at the concurrency the scale run required.

What limited the on-premises pipeline

On Zimmer Biomet’s internal infrastructure, the pipeline ran effectively but serially with limited parallelization, at a concurrency governed by the size of the in-house compute resources and the local license pool. Getting from that to 30,000 successful simulations in 24 hours required raising sustained throughput by roughly three orders of magnitude for a short period, which was not possible on-premises where the compute capacity is sized for everyday workloads.

Cloud is the obvious answer for such burst capacity, but “move it to the cloud” understates the work. The specific problems the team had to solve included:

• Environment fidelity – Three commercial packages plus proprietary code, across Windows and Linux, installed and licensed identically on every one of thousands of ephemeral virtual machines.
• Heterogeneous scheduling – Single-core Windows steps and multi-core Linux solver steps have to scale independently, or one starves the other.
• State for tens of thousands of workflows – Each simulation is a seven-step state machine. At any moment, thousands of them are in different states, including failed states.
• Failure handling at scale – At 30,000 simulations, a 1 percent failure rate is 300 failed jobs. Finding them has to be automatic.
• Regulated-grade traceability – For results to support a regulatory submission, the execution has to be auditable—what ran, when, on what input, with what outcome, and what was retried?
• Data movement and shared storage – Input decks, intermediate artifacts, and results have to be visible to every Windows and Linux node in the fleet, at fleet-wide I/O rates.

The Virtual Surgery Simulation Orchestrator

Invisibl Cloud, an AWS Partner, designed and built a custom orchestration system to solve these problems: the Virtual Surgery Simulation Orchestrator. The core design decision was to stop treating a simulation as a job and start treating it as a workflow of independently scalable stages. The following diagram illustrates the solution architecture.

Figure 3: Architecture of the Virtual Surgery Orchestrator. The PostgreSQL-based queue and state management decouples the preprocessing, solve, and postprocessing, each served by its own automatically scaled fleet, with an Amazon Aurora Serverless v2 database holding per-simulation state and Amazon FSx for NetApp ONTAP as the shared data plane. (Credits: Invisibl Cloud)

Pipeline with model queues and three fleets

The entire workflow shown in Figure 2 was split into two parts, the virtual surgery of Step 1 and the pipeline execution (Steps 2–7).

The pipeline execution is split at its natural seams into three stages, each orchestrated using the PostgreSQL-based queue and its own fleet:

• Preprocessing – Steps 2–5, on a fleet of Windows Amazon Elastic Compute Cloud (Amazon EC2) instances
• Simulation – Step 6, the Abaqus solve, on a Linux HPC cluster deployed with AWS ParallelCluster and managed by Slurm
• Postprocessing – Step 7, on a second Windows EC2 fleet

The Step 1 virtual surgery was performed on Zimmer Biomet’s premises ahead of the scale run due to the required access to virtual patient models and internal implant databases (with data privacy and IP restrictions), and is excluded from the 24-hour turnaround time reported. Additionally, this step also required the actual definitions of finite element analysis (material properties, contact definitions, mesh sizing, boundary conditions, and so on), which were slightly different based on the implantation configuration and analyzed failure mode. The virtual surgery step generated all required input files and configuration for all simulations. A total of 55,846 simulations were planned, allowing for inherent failures of some FEA runs, to yield at least 30,000 successful simulations. All the model input files were uploaded to an Amazon Simple Storage Service (Amazon S3) bucket, and an ingestercomponent wrote those inputs to shared storage.

Running 55,846 simulations within 24 hours requires a high degree of parallelism. The orchestrator platform achieves this by automatically scaling thousands of worker instances to run multiple model simulations in parallel. For the full-scale run, the orchestrator batch run was configured to run 1,500 simulations concurrently.

When a batch run is triggered through the orchestrator platform UI, the orchestrator backend service creates the initial state record for each model simulation and marks the first 1,500 of the 55,846 models as pending for preprocessing. That single action starts the trial. From there the flow is entirely message driven. A worker service running on the Windows preprocessing fleet picks up a message, runs Steps 2–5, updates state, and updates the model queue state as pending for simulation. A SLURM bridge worker running on a Linux control server consumes that message, translates it into a Slurm job script, submits it with sbatch, tracks the job through squeue and sacct, and on success publishes to the postprocessing queue. The same worker service, running on the postprocessing fleet, executes Step 7, writes the final outputs, and marks the simulation as complete.

The orchestrator continuously monitors the model status in the queue and as the model simulations complete, the orchestrator replenishes the pending model queue with more models, up to 1,500 in a sub-batch. The pipeline workers continuously keep processing as the models become available in the queue and the entire pipeline executes seamlessly.

Decoupling the stages this way makes the resource mismatch in Figure 2 tractable. The Windows fleets scale on single-core instances sized for single-threaded work. The Slurm cluster scales on compute-optimized instances sized for the solver. Neither one waits for the other, and neither is provisioned for the other’s shape.

Stateless workers, state in PostgreSQL

Every component in the orchestrator is stateless. All states live in Amazon Aurora PostgreSQL-Compatible Edition, using Aurora Serverless v2, in three tables:

• SimulationState – One row per simulation, keyed on simulation_id, holding the current status, per-step status, start and end timestamps for the simulation and for each individual step, retry counts, the Slurm job ID, and I/O paths. Status moves through a defined set of constants, from CREATED through PREPROCESSING_IN_PROGRESS, SIMULATION_RUNNING, POSTPROCESSING_IN_PROGRESS, to COMPLETED or FAILED.
• SimulationAuditLog – Append-only, keyed on simulation_id and an ISO-8601 event time. Every state transition, retry, and failure is recorded with the component and worker that produced it. This is the table that makes the run auditable.
• PipelineStepMapping – The mapping from each step codes to descriptions and pipeline phases, so reporting groups steps consistently.

Keeping workers stateless has a practical payoff: instances can be terminated and replaced as needed without losing a simulation, and simulations can be rerun from a known state. The workers reach the database through Amazon RDS Proxy, which pools their connections.

Auto scaling on model queue size

A custom FleetAutoScaler was implemented as part of the orchestrator. It watches queue size, scaling thresholds, and error rates, and sizes the Windows preprocessing and postprocessing fleets accordingly, within configured minimum and maximum bounds. Putting the scaling logic in a purpose-built controller rather than relying on basic Auto Scaling group metrics helps the team express policies specific to this pipeline—scaling on the number of messages waiting for a particular step rather than on aggregate CPU.

Shared data plane

Amazon FSx for NetApp ONTAP provides a single shared file system mounted across the Windows fleet instances, the SLURM bridge server, and Linux HPC compute nodes. It holds input files, intermediate artifacts, simulation outputs, and final results. Having one namespace visible from both Windows and Linux, at fleet-wide throughput, allows the three stages to pass work off to each other by reference rather than by copying data.

Visibility

An API server backed by PostgreSQL, with a React dashboard in front of it, gives the team a live view of the run: overall progress, per-simulation drill-down, step timings, failure details, and the ability to retry. Worker logs stream to Amazon CloudWatch. During a 24-hour run involving tens of thousands of simulations, this live view is essential. Without it, the honest answer to “How is the run going?” is “We will know tomorrow.” Figure 4 shows an example.

Figure 4: The orchestrator dashboard’s execution flow for a single simulation, showing the status and duration of each pipeline task (Credits: Invisibl Cloud)

Getting to scale: Capacity, instances, and the failure budget

Designing the architecture was the first half of the problem. Achieving 30,000 successful simulations inside 24 hours surfaced a set of very practical constraints.

Compute capacity and quotas

The scale run required approximately 25,500 physical cores (51,000 vCPUs) at peak and was executed in the AWS Europe (Frankfurt) Region (eu-central-1), with the compute queues configured to draw from all three Availability Zones (eu-central-1a, eu-central-1b, eu-central-1c). Spreading across Availability Zones materially improves the probability of acquiring several thousand instances on demand simultaneously.

Because the SLURM configuration was flexible about instance types, the team was able to consider EC2 Capacity Reservation Fleets, which spread a compute request across a range of instance types up to a target vCPU capacity, as an on-demand mechanism for assembling that much capacity in a single window. Instance-type flexibility in the scheduler makes that option available; a configuration pinned to one instance type forecloses it.

Instance selection

The EC2 instance families were chosen per stage, matching the resource profiles in Figure 2. The following table summarizes the instance types configured for each pipeline stage.

Listing several generations per stage was deliberate. It gives the scheduler alternatives when a specific instance type is constrained, and it lets the team trade cost against performance without re-architecting. The memory-optimized R family is included for the preprocessing and postprocessing fleets because some of those steps are memory-bound rather than CPU-bound. In the full-scale run, 1,500 Windows instances (r8i.large, r7i.large, and r6i.large) ran preprocessing and postprocessing, and 1,500 Slurm compute nodes (c8i.8xlarge and c7i.8xlarge) ran the Abaqus solves, about 3,000 instances in total.

Budgeting for failure

At this scale, some simulations will fail—virtual surgery resulting in CAD models that didn’t create solid bodies or that contain tiny volumes or faces resulting in a failure to generate three-dimensional finite element mesh or in highly distorted elements that don’t pass the quality check of the FEA solver, FEA solves that diverge, or cases that land outside the intended parameter space. Although it’s often possible to overcome these typical FEA challenges by manually adjusting certain FEA parameters, fixing tiny CAD faces and volumes, and so on, those manual fixes aren’t feasible in a scale run. Furthermore, finding a common recipe for the FEA model setup that can be applied automatically and that will work 100 percent of the time proved to be impossible. Therefore, the team planned for a failure rate of about 25 percent and submitted 55,846 simulations to secure at least 30,000 successful results. In the full-scale run, 46,662 simulations succeeded, a success rate of 83.6 percent. Most failures came from problematic meshing of CAD geometry (11.2 percent of submissions), followed by FEA non-convergence (2.9 percent) and input errors from the virtual surgery step (2.1 percent).

The team also ran a 5,000-simulation test run before the full-scale run, which exercised every part of the system—queues, auto scaling, licensing, storage throughput, failure handling—at a scale large enough to expose real problems but small enough to iterate on. This also helped estimate the failure rate, making it possible to correspondingly size the total number of submitted jobs in order to obtain 30,000 successful results. Significant issues that could occur in the full-scale run had already been identified by that test and fixed.

Results

The verification runs and the full-scale run produced the following results:

• The cloud implementation reproduced the on-premises results to within 1 percent, with the small differences attributable primarily to meshing. This was the gating result for everything else: a faster pipeline is useful only once it has demonstrated results equivalent to those from the validated on-premises pipeline.
• The architecture demonstrated linear scalability across the test runs, which made the full-scale target predictable before it was attempted.
• The full-scale run completed 46,662 successful simulations, covering 23,311 virtual shoulder surgeries across 155 anatomies, in about 23.5 hours of wall-clock time. Each anatomy received up to 148 virtual surgeries, spanning stem design, stem size, and alignment. A subset with one stem design was also analyzed with low bone quality. In total, the surgeries amount to roughly twice the annual total shoulder arthroplasty volume of the United Kingdom or of Australia.

Measured against the baseline of 1,042 simulations done on-premises in about 3 months, the scale run delivered about 45 times as many successful simulations in a single day.

The larger cohort enabled previously observed trends to reach statistical significance. For example, the effect of stem alignment (varus or valgus tilt) on relative stem size, a trend in the original study, was statistically significant in 13 of 15 comparisons with 23,311 virtual surgeries (p < 0.05).

The orchestration layer also improved the output. The pipeline generated analysis-ready results automatically in Step 7, and the monitoring tooling produced run-level execution summaries for traceability, including systematic identification and management of failed simulations. Model preparation still takes time: setting up the inputs so the full cohort could run in a single day took several weeks, and the scripted postprocessing analysis still depends on engineers writing scripts and interpreting the data. What the cloud removed was the months of waiting for execution.

Figure 5 shows the full-scale run as the orchestrator dashboard recorded it: running and pending simulations over time, and cumulative completions climbing steadily.

Figure 5: Orchestrator dashboard summary of the full-scale run, showing running, pending, and cumulative completed simulations over time. Its instance count covers the Windows fleets, the orchestrator, and the Slurm controller. (Credits: Invisibl Cloud)

How this improves medical device development

Running a trial of this size in a day improves at least three things in the medical device development workflow:

• For implant design – More than 46,000 simulations in a day means the in silico trial stops being a validation milestone and starts being an engineering design tool. A design question that would previously have been answered with engineering judgment, because the virtual trial to answer it properly would take months, can now be answered with data before the design is frozen.
• For regulatory evidence – Larger virtual cohorts support broader sensitivity and uncertainty quantification, better characterization of extremes, and more robust assessment of design and surgical factors, because the bias effects that come with small-sample sampling are reduced. Complication modes that occur at low single-digit rates—the ones a 100-patient trial can’t characterize—become tractable. Now we can identify potential problems in rare cases and address them before the first patient gets implanted.
• For patients – This part matters most. Every month cut from the evidence-generation timeline is a month earlier that a better implant reaches the patient who needs it. Conversely, if a clinically underperforming design can be detected in a virtual cohort before it’s actually implanted in a real patient, harm and distress may be prevented. Compressing the computational portion of that timeline from months to a day removes one of the larger fixed delays in the regulatory pathway, and it does so while producing more robust evidence. Additionally, it becomes a useful tool for design evaluation, iteration, and optimization that is available within the design development lifecycle to accelerate innovation. For a patient waiting on a shoulder that works, the difference between innovation arriving in 5 years and arriving in 3 years matters.

Looking ahead

The tool stack built for this project can be reused for other implants, joints, and endpoints, and a wide variety of other medical devices. The immediate next step is exactly that: Zimmer Biomet is deploying the orchestrator to accelerate future in silico trials.

Beyond that, a dataset of more than 46,000 simulations with full mechanical outcomes is a training data corpus. The team is exploring surrogate modeling—training machine learning models on this dataset to approximate finite element outcomes in milliseconds rather than 75 minutes per model. When that works, the sequence is instructive: cloud HPC makes it feasible to generate a dataset at a scale that was previously impossible, and that dataset then makes a fundamentally faster AI-based method possible. The acceleration described here might turn out to be the enabling step.

Conclusion

An in silico clinical trial that took 3 months now runs at about 45 times the scale in a single day. The pieces that got us there are powerful building blocks: a PostgreSQL-based queue and state store, a Slurm cluster, two auto scaled Windows fleets, a shared FSx for NetApp ONTAP file system, and a purpose-built orchestrator to tie them together. The biggest challenge was the discipline of decomposing a real, validated, seven-step engineering workflow that spans two operating systems into something that could run 1,500 simulations at a time and still produce results with the traceability that regulated work requires.

The faster pipeline changes what computational evidence can do in medical device development—and, downstream of that, how quickly a better implant reaches a patient.

If you’re working on scaling engineering simulation or in silico trials on AWS, we would like to hear about it. You can reach us through the AWS HPC team.