Seeking Feedback: Dynamic DICOM Endpoints + Progress

[blitzboah]

Hello everyone,

I have been working on a proof of concept (PoC) for a DICOM routing utility that dynamically forwards incoming DICOM images to the least loaded Orthanc instance. The goal is to optimize medical imaging storage and prevent bottlenecks in PACS-like systems. This project is designed to improve efficiency in distributed DICOM deployments, supporting use cases such as teleradiology and federated learning.

After implementing the initial PoC, I would like to discuss possible improvements, alternative approaches, and potential integrations with other DICOM frameworks.
✅ Current Features:

DICOM Listener: Listens for incoming DICOM images via storescu.
Dynamic Routing: Determines the least loaded Orthanc instance and forwards images.
Verification with curl: Allows checking stored instances in the assigned Orthanc server.

🔜 Next Steps:

Enhancing Load Balancing Logic: Should routing be based only on queue size, or should metadata like modality (CT, MRI, X-ray) be considered?
Performance Improvements: Exploring batch processing or multithreading for large-scale DICOM ingestion.
Improved Error Handling & Resilience: Implementing fault tolerance to handle failed Orthanc nodes.
Potential Integrations: Could this utility be combined with existing DICOM frameworks like Niffler or Dicoogle for advanced search and indexing?

📝 Seeking Feedback On:

Is routing purely based on queue size effective, or should we consider additional metrics (CPU load, network latency, etc.)?
Would HAProxy or Kubernetes-based auto-scaling be a better long-term approach?
Any references or best practices for dynamic DICOM routing?
Currently using Python—are there better-suited technologies for handling high-throughput DICOM processing?

🔗 GitHub Repository: https://github.com/blitzboah/dynamic-dicom-endpoints

@pradeeban

[pradeeban]

Is routing purely based on queue size effective, or should we consider additional metrics (CPU load, network latency, etc.)?
Queue size is a good start, given it is DICOM.

Would HAProxy or Kubernetes-based auto-scaling be a better long-term approach?
Feel free to propose it in your GSoC proposal. Maybe, mark it as "Optional" or "if time permits."

Any references or best practices for dynamic DICOM routing?
The classic routing is end-to-end. You should be able to find several references, including some on Niffler.

Currently using Python—are there better-suited technologies for handling high-throughput DICOM processing?
Python is a good choice. But feel free to propose alternatives!

[blitzboah]

hi @pradeeban

currently, the project is CLI-based, and i'm considering whether this is the best approach moving forward.

i'm wondering if a REST API or a Web Dashboard would be a better way to expose this functionality, especially for real-world deployments. would it make sense to keep it CLI-based, or would a different approach be more practical?

would love to hear your thoughts on what would work best in real-world medical environments!

[pradeeban]

Hi @blitzboah, REST APIs are great. Then you could build a web dashboard that would consume the REST API. We definitely shouldn't just have a web dashboard that is tightly coupled to the functionality though. We should be able to invoke the functionality programmatically - which is possible with the CLI-based and REST-based approaches.

[blitzboah]

Hi @pradeeban, thanks for the input!

I am almost done with basic CLI-based implementation and now planning to extend the project with a REST API.
Repository - https://github.com/blitzboah/dynamic-dicom-endpoints

Next Steps:

• Design API endpoints for uploading DICOM files, checking instance stats, and managing Orthanc servers.
• Implement the API using Flask or FastAPI to expose these functions.
• Once the API is stable, explore building a web dashboard for visualization.

Would you recommend any additional API features that could make the system more useful in real-world medical environments?

[pradeeban]

I think these are good. A plan for testing will be a great addition. For instance, configuring one Orthanc with some DICOM images as the PACS server, while using another to probe and receive images from.

[blitzboah]

hi pradeeban sir ,
i’ve successfully configured orthanc servers, one as a probe to receive images, and made the setup easier using docker. the testing and web parts are next on my list, and i’ll be working on them soon. once those are done, we can proceed with configuring niffler and setting up the database integration.

here’s the flow of my implementation:

let me know if you have any suggestions or feedback on the setup!

repo: dynamic dicom endpoints

[pradeeban]

That looks great.