March 2026 Cycle Report

Published 11 March 2026

💥 Optimizing Algorithm Execution: Introducing the Invoke Method¶

Running an algorithm job normally consists of a number of steps: loading the algorithm Docker container, loading the model and input data, and executing the container's entry-point. The user's code instantiates the model and processes the input data. When multiple jobs are executed for the same algorithm, this entire process is repeated for each job. We refer to this as the exec method.

For most cases, this workflow will remain unchanged as it ensures that consecutive model inferences are completely independent. However, there are situations where it is beneficial to pay the overhead of starting the container, loading the model and data, and instantiating the model, only once. For example:

• when using an interactive algorithm in reader studies, or
• when the test set of a challenge contains many cases (>1000), but each inference job would only take a few minutes. The relative high overhead of the initialization step has a negative impact on both the budget and the run time of these challenges.

In this cycle we have implemented a new method that allows algorithm containers to be loaded once and invoked multiple times to perform model inference. We refer to this as the invoke method.

In future cycles we will make adjustments for reader studies and challenges to take advantage of these long-running algorithm containers. This will enable running algorithms with GPUs for reader studies (currently algorithms must be adapted to be interactive and CPU-only) and will remove the need for stacking images when there are many cases in a challenge test set. Stay tuned to hear when this new execution method becomes available!

😊 Friendlier Challenge-Hosting Requests¶

With the upcoming MICCAI-related challenges, we've spent some time making the process of requesting a challenge on our platform easier. Making a request to host a challenge used to require filling in a lengthy web form that needed all the details of the planned challenge upfront.

We've shortened the initial request form to just three fields: title, acronym, and contact email address. The resulting draft can then be edited and updated incrementally. Once the request contains all the required information, submitting it for review is a simple press of a button.

Content-wise, we've also made some major improvements to the request:

• Clear sections indicate which fields are required and which are optional
• Pre-existing submission forms from MICCAI can be uploaded directly, saving you from manually transferring all the fields from the document into the web form
• The budget estimation fields (such as average algorithm runtime) have been replaced with a more flexible free text field

We look forward to new challenge requests!

Viewer Rendering Migrated to ECS¶

We have migrated our viewer rendering infrastructure from Docker to Amazon Elastic Container Service (ECS). This allows us to scale out horizontally within a single region so that more users are able to access reader studies simultaneously. It has also simplified our technology stack, lowered viewer latency and improved availability.

🎯 Faster Case Navigation when using Auto-Jump to Center of Gravity¶

The CIRRUS feature "auto-jump" moves the view of CIRRUS directly to an overlay when a case is loaded for the first time. However, this requires computing the center of gravity for each displayed overlay, which increased loading times in reader studies. This delay can be long if the overlays are big.

To solve this problem, we implemented a streaming compute step that computes the center of gravity for overlays of follow-up cases in a reader study. While readers read a case, the center of gravity for one follow-up case is precomputed. Although the first load of a reader study is still slow, navigating to a follow-up scan should be much faster for readers. This should make it faster for readers to progress through a regular reader study that uses the auto-jump feature.

Migration of UI framework for CIRRUS¶

As a team we use a framework that provides standardized user interface (UI) components called Bootstrap. In CIRRUS we were using a library called BootstrapVue for this. This library has been deprecated for a while and a successor called BoostrapVueNext has matured enough for us to decide to migrate. This migration has been done in this cycle. There are some small noticeable changes in UI components coming from this migration, but there should be no functional changes.

Cover photo by Chris Barbalis on Unsplash