July 2025 Cycle Report

Published 10 July 2025

First steps towards full DICOM support¶

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 transition will be delivered in multiple phases:

DICOM ingestion & de-identification: Define and implement how uploaded DICOM files are de-identified before storage.
AWS HealthImaging integration: Adopt AWS HealthImaging, the service we’ve selected to store and manage DICOM files securely and efficiently.
Platform-wide updates: Update all platform components that handle medical imaging — including Archives, Reader Studies, Algorithms, and viewers — to support native DICOM workflows.

In this cycle, we have started working on the first phase, defining and implementing de-identification procedures.

📋 DICOM De-Identification Procedure¶

We require all users to anonymize their images before uploading it to our platform. Still, as we prepare the Grand Challenge platform to support the DICOM standard, we’ve taken steps to implement our own de-identification process for these DICOM files. Think of it as an extra layer of precaution and not a replacement for the anonymization users are responsible for. Those who manage the data, afterall, know much better what information is unnecessary than any one-size-fits-all approach ever could.

To support this effort, we’ve put together a procedural framework that spells out how each data element in a DICOM image should be handled. For every tag, we decide whether to keep it, swap it with a dummy value, or remove it altogether from the headers. This process is based on the basic confidentiality profile in the DICOM standard, with one key addition: if we’re unsure about a tag, we play it safe and remove it.

For example, DICOM attributes like "Patient's Age" are clearly removed, while "Pixel Data" is kept unchanged. Of course, plenty of other attributes fall into more of a gray area. You can read more about how the de-identifcation procedure was created here.

Our de-identification procedure is defined per SOPclass, for this first implementation we selected the SOPclass describing a CT image. More SOPclasses will be added in future iterations.

✨ Client-side implementation of de-identification procedure¶

In addition to developing the new DICOM De-identification Procedure during this cycle, we also focused on implementing it. We chose to start with a JavaScript-based solution that will serve as a first line of defense when users upload DICOM files containing patient information. Our goal is to minimize the risk of this sensitive data reaching our servers. To achieve this, we will perform the de-identification process locally on the user's machine before any data is uploaded. Currently, this implementation is disabled but will be activated in the future as part of our ongoing DICOM support efforts.

📖 Smarter Search, Clearer Answers¶

We’re committed to providing clear and comprehensive documentation. While our documentation includes explanations and tutorials, we know information was sometimes hard to find. We’ve made two key improvements to help:

🔍 Better Search Results: Search results now display breadcrumbs and a headline, making it easier to judge their relevance. When you click a result, the headline is highlighted on the page, so you can quickly spot where the information appears.

❓New FAQ Section: We’ve added a dedicated FAQ section that presents information in a simple Q&A format. This makes it easier to find quick answers without interrupting the flow of a full tutorial.

FAQ

💾 Autosaving of answers in Reader Studies¶

We implemented a new autosaving feature that can be used on reader studies that also have allow answer modification enabled. To enable autosaving, go to grand-challenge page and open the settings-page for a reader study. There, you will find a new option for "enabling autosave" for reader studies :

When enabled, autosaving of answers automatically saves a reader's progress as he/she answer questions of a reader study. Autosaving is done in the background so it does not interfere with regular reading of a reader study. The feature prevents accidental data loss when a reader study session gets interrupted unexpectedly or a reader closes the browser window.

There are some caveats for verified and accept/reject questions: autosave will not occur if the answers to the question are partial or invalid. For validated questions, autosaving will only happen if the data entered complies with the specified verification pattern. And for accept/reject type questions, all findings need to be answered for autosaving to work.

Cover photo by Jack Millard on Unsplash