Using metadata and telemetry for routing decisions in Dynamic DICOM Endpoints

[AtharvaKathe18]

Hi @pradeeban and @anbhimi,

I’ve been going through the discussions around the Dynamic DICOM Endpoints project and exploring the Diomede repository to understand how routing and orchestration might be implemented in practice.

From the previous discussions, it seems that one possible direction is to have Diomede act as a stable DICOM endpoint and route studies to different Orthanc/PACS nodes based on system state (queue depth, availability, etc.), while still maintaining compatibility with the static endpoint expectations of DICOM devices.

While working on a few recent improvements around metadata extraction and query validation, I started wondering whether metadata itself could also play a role in routing decisions.

For example, when selecting a destination node, could routing logic consider factors such as:

• Modality (e.g., CT, MRI, etc.)
• Study size or number of instances in a series
• StudyDate or study priority
• storage characteristics of backend nodes

This might allow the system to distribute workloads more intelligently (for example sending larger studies to nodes with more available storage or faster network paths).

I’m also curious whether the project envisions maintaining some form of central telemetry state (for example via Redis/PostgreSQL) that tracks node health, queue depth, and transfer performance.

I’d love to hear your thoughts on how much of the routing logic is expected to rely on system telemetry vs DICOM metadata characteristics.

Thanks!

[AtharvaKathe18]

Hi,

I wanted to share a quick update based on my earlier question around metadata and telemetry-driven routing.

To explore this further, I implemented a small working prototype of a DICOM routing layer using pynetdicom.

The prototype includes:
• A router acting as a DICOM SCP that receives and forwards datasets
• Metadata extraction (Modality, PatientID, StudyDate)
• Routing decisions based on metadata and estimated dataset size
• Basic load balancing using telemetry (per-node request counts)
• Cached node availability checks to avoid frequent health probing
• Transfer latency measurement for each forwarded dataset

I also set up mock destination nodes to simulate a distributed environment and validate routing behavior end-to-end.

I’ve uploaded the implementation here for easier review:
https://github.com/AtharvaKathe18/dicom-routing-prototype

This helped me better understand how routing decisions could incorporate both DICOM metadata and system-level telemetry.

I’m currently exploring how these signals (latency, workload, etc.) could be extended further and how they might integrate with dynamic endpoint selection in Diomede.

Would really appreciate any feedback on whether this direction aligns well with the project goals or if there are specific aspects I should explore next.

Thanks!

[pradeeban]

Interesting approach and prototype, @AtharvaKathe18. Any C-MOVE compatible parameter could be used to direct towards a specific endpoint, I believe. So, modality works.

[AtharvaKathe18]

Thanks, that’s really helpful.

I’ll look into how C-MOVE parameters (like query keys and identifiers) can be leveraged to influence routing decisions in a way that stays aligned with standard DICOM workflows.

It would be interesting to explore whether routing decisions can be integrated at the query/retrieve level (C-FIND/C-MOVE) rather than only at the C-STORE forwarding stage.

I’ll experiment a bit in this direction and see how it fits with the current prototype.

Thanks again for the insight!

[pradeeban]

If you check Niffler cold-extraction module, we used C-FIND and C-MOVE in conjunction.

[AtharvaKathe18]

Thanks, that’s helpful.

I’ll take a look at the Niffler cold-extraction module to understand how C-FIND and C-MOVE are used together, and see how that can be applied here. It should give a better idea of how to align routing with standard workflows.