[14] Dynamic DICOM Endpoints - GSoC 2026 Proposal: Dynamic DICOM Endpoints for Optimized Radiographic Data Distribution

[jess-tech-lab]

Personal Introduction

Hi @pradeeban and @ananthreddy2580,

I am writing to express my strong interest in the Dynamic DICOM Endpoints project. After reviewing the Diomede repository and the project's goals, I am excited to propose a solution that transitions radiographic communication from static configurations into an intelligent, load-aware network.

Project #14 of GSoC 2026 attracts me specially because it addresses a critical physical bottleneck in teleradiology. As a Computer Science student with a background in Python REST API development and crowdsourced security research, combined with my training in clinical and public health, I possess a multidisciplinary perspective. I understand not only the code required to build a high-performance orchestration layer but also the clinical urgency behind the data it carries. I am confident that my experience in hardening infrastructure and managing network telemetry makes me the right fit for Diomede, and I look forward to the possibility of contributing to the KathiraveluLab and the University of Alaska Anchorage community.

1. Abstract

Traditionally, DICOM communication relies on static configurations (IP, Port, AE Title), creating bottlenecks in teleradiology and hindering federated learning on radiographic images. This project proposes a dynamic orchestration layer for DICOM endpoints. By deploying Orthanc instances globally and utilizing a Python-based middleware to monitor network health and server load, we will transition DICOM from a "static-pipe" protocol with possible queuing delays to an intelligent, load-aware distribution network.

2. Technical Background & Experience

2.1 Python Development

I am an experienced Python developer specializing in building scalable automation tools and backend services. My work frequently involves asynchronous programming and RESTful API integration.

2.2 Security Background

With an active background in crowdsourced security research, I prioritize the "Security by Design" principle. DICOM data contains sensitive Protected Health Information (PHI). My experience identifying vulnerabilities in web infrastructure allows me to architect the Central Configuration and Dynamic Routing components with a focus on:

• Securing the Orchestrator: Preventing unauthorized endpoint redirection
• Encryption: Ensuring TLS 1.3 across all global Docker nodes
• Authentication: Hardening AE Title validation to prevent spoofing

2.3 Networking Knowledge

I possess a deep understanding of the OSI model, specifically Layer 4 (TCP) where DICOM operates and Layer 7 (HTTP) for Orthanc’s REST API. I am comfortable managing VPCs, subnets, and latency-based routing in a cloud deployment, which is essential for simulating a global PACS environment across different regions.

3. Proposed Methodology & Implementation

Phase 1: Global Simulation Environment (Infrastructure)

To simulate a real-world teleradiology use case, I will deploy multiple Orthanc instances using Docker across various Google Cloud Platform (GCP) Regions (e.g., us-east1, europe-west1, asia-northeast1, and africa-south1).

This setup provides measurable "real-world" latency and jitter. And each instance will be containerized for rapid scaling and reproducibility.

Phase 2: Telemetry & Monitoring (The Status Table)

I will utilize Orthanc REST API to develop a Python-based Monitor Service that:

• Queries the /statistics and /changes endpoints of each Orthanc node
• Performs periodic "heartbeats" to measure Round Trip Time (RTT) and throughput
• Stores these metrics in a Central Configuration Store (e.g., Redis for speed or PostgreSQL for persistence)

Phase 3: Dynamic Routing Logic (The Orchestrator)

The core of this project is the Diomede Orchestrator, which acts as a traffic controller:

• Client Request: A source (e.g., a CT scanner) queries the Orchestrator before sending an image
• Decision Engine: The Python engine calculates the "Best Fit" node based on
  • Geographic Proximity: Minimizing latency
  • Queue Depth: Avoiding nodes currently processing large batches
  • Availability: Health-check status from the central configuration
• Redirection: The Orchestrator returns the optimal destination AE Title and IP to the client

Phase 4: Dynamic Source Selection

When a radiologist requests an image, the system must determine the most efficient source. If the image is replicated across multiple nodes (federated approach), the Orchestrator will direct the request to the node with the lowest current egress load, ensuring high availability and speed.

4. Week | Milestone | Key Deliverables

Week	Milestone	Key Deliverables
1-2	Community Bonding	Gather requirements and determine implementation plan with mentors; finalize GCP architecture
3-4	Infrastructure Setup	Deploy Orthanc Docker containers globally; script health-check monitoring
5-7	Backend Development	Build the Python Monitoring Service and Central Database Management
8-11	Orchestration	Implement the routing algorithm; create the prototype "Redirector"
12-15	Testing & Documentation	Stress tests (high-volume transfers) and create final README, Wiki, and deployment guides

[pradeeban]

Looks good, @jess-tech-lab. Pls go ahead with your proposal.

[jess-tech-lab]

Thanks @pradeeban for the advice! I’ve submitted a draft of my GSoC proposal. I’d really appreciate any feedback you might have, especially on the scope and technical approach. I’m happy to revise it based on your suggestions. Thanks for your time!

[pradeeban]

I went through your proposal @jess-tech-lab. It is well-written with scope of both coding (the core aspect of GSoC) and research. You have tagged a wrong Ananth. Tagging the correct one here for his feedback: @anbhimi

[jess-tech-lab]

Thanks @pradeeban a lot for taking the time to review my proposal. I really appreciate your prompt feedback. Apologies for tagging the wrong Ananth earlier, and thank you for looping in @anbhimi. I look forward to hearing his advice as well.

[Pragya-rathal]

This is a really detailed proposal, especially the way the orchestration layer and telemetry pipeline are structured.

I was going through this along with the earlier discussions, and I’m curious about how this would integrate with higher-level workflows like metadata querying or album generation.

If some form of routing or replication already exists/planned at the infrastructure level, how would consistency be handled when:

• datasets are distributed across multiple nodes, and
• queries (e.g., modality/date filters) need a unified view?

Would this require a separate metadata index layer that abstracts physical storage, or is the orchestration layer expected to handle that indirectly?

I’ve been exploring the metadata/query side, so trying to understand how these layers might connect.

[jess-tech-lab]

Thanks @Pragya-rathal for the kind words and the thoughtful question! Just to clarify, the dynamic endpoint design in my proposal is scoped to upload and download routing only. Query like QIDO-RS with DICOMweb is out of scope for this GSoC proposal. That said, since federated learning naturally distributes datasets across nodes, the node registry that the orchestrator maintains could serve as the foundation for distributed queries down the road.

[pradeeban]

Thanks @jess-tech-lab for the clarification. There is also a considerable research involved. There are certain limitations imposed by DICOM itself as a messaging protocol. We do not have to have answers for everything during the application stage. Ok to leave questions in the proposal that we will eventually figure out during the community bonding period (or later during the coding period!).

[Sahil-u07]

congrats @jess-tech-lab

[jess-tech-lab]

Thank you! I’m grateful to the mentors @pradeeban and @anbhimi for their guidance and support throughout the process. I’m excited to get started, contribute to the project, and learn along the way!

[pradeeban]

Congratulations, @jess-tech-lab
I have sent you all an email to have the first onboarding meeting for tomorrow. Please reply with your availability.

[jess-tech-lab]

I’ve replied with my availability. Excited for the onboarding meeting!

[httpsVishu]

@jess-tech-lab congrats!