November 2025 Cycle Report

Published 25 Nov. 2025

DICOM is the international standard for storing and exchanging medical imaging information. Our platform has supported DICOM data for many years by converting these files into either the SimpleITK format (for radiology) or TIFF (for pathology).

This approach has several advantages — such as improved data reusability across the platform and a straightforward, pixel-data–oriented workflow. However, it also comes with limitations: algorithms on the platform must work with data formats that are not commonly used in clinical practice, and valuable metadata embedded in DICOM tags is lost during conversion.

As demand grows for storing and processing DICOM in its original form — preserving both the pixel data and metadata — we have started work on full native DICOM support on our platform. This will allow us to host algorithms that operate directly on DICOM, aligning more closely with clinical workflows.

This cycle, the last of the required features were implemented to make DICOM use possible end-to-end. If you would like to use DICOM on our platform, contact us at support@grand-challenge.org to set things up.

🛡️Add DICOM MR to de-identification profile library¶

The public profile library describes our policy for de-identifying DICOM. For each supported Information Object Definition (IOD), a new profile is created. This cycle the list of supported IOD's was extended with the DICOM MR IOD.

🔬Viewing AWS HealthImaging Data in the Pathology Client Side Viewer¶

Pathology images are displayed in the browser using a client-side viewer built on OpenSeadragon. OpenSeadragon enables smooth interaction with extremely large images—often several gigabytes—by loading them as tiles instead of requiring the full file to be downloaded. For pathology images stored in TIFF format, the corresponding tile format is DZI. All pathology images uploaded to an Image socket on Grand Challenge are automatically converted to DZI to support this viewer.

For DICOM WSI, we implemented a custom OpenSeadragon tile source. This tile source handles the translation between OpenSeadragon’s coordinate system and that of DICOM WSI, and it retrieves the appropriate image data from AWS HealthImaging. The retrieved data is decoded in parallel using multiple Web Workers, improving performance and keeping the viewer responsive.

🩻 View AWS HealthImaging radiology data in Cirrus¶

Work on the server-side viewing of DICOM images began last cycle and was completed in this one. During implementation, we encountered several challenges, including limitations on the number of parallel downloads, quirks in how MeVisLab (the underlying software for our server-side viewer) loads DICOM tags, and caching issues that only became apparent during testing.

🔃 Create Staging environment for end-to-end testing of AWS HealthImaging¶

To validate the newly implemented DICOM support, we set up a staging environment that allows end-to-end testing of the entire workflow. This includes uploading DICOM images (via both the UI and the API), provisioning DICOM data to algorithms, using DICOM in Reader Studies, and viewing DICOM within Archives and Algorithm jobs.

💥 Upload DICOM with gcapi (breaking changes!)¶

Uploading large numbers of files to Grand Challenge can be time-consuming. To support users with this and other repetitive tasks, we provide the GCAPI Python package—a Python client for interacting with the Grand Challenge API. During this development cycle, we extended GCAPI with DICOM support and made several usability improvements.

When uploading data to a DICOM Image Set socket, GCAPI now de-identifies the files client-side before sending them to Grand Challenge, reducing the risk of exposing sensitive data. The platform then applies its own de-identification once the files arrive. Note that this does not remove the user’s responsibility to ensure that personal information has been properly removed—our de-identification pipeline is general-purpose and assumes that the DICOM standard has been followed correctly.

⚠️ We also used this opportunity to make method and argument naming within GCAPI more consistent across the package, resulting in a number of major changes. Please have a look at the dedicated blogpost regarding these breaking changes.

Cover photo by Kalen Emsley on Unsplash