How It Works
A distributed client-server architecture for autosegmentation
DRAW uses three components — a lightweight client, an API server, and ephemeral GPU instances — to deliver automatic segmentation without requiring local GPU hardware.
System Architecture
The DRAW system comprises three components: a client, an API server, and ephemeral GPU instances which are created on demand.
The DRAW client and server have been designed using similar software stacks to ease maintenance. The backends in both applications have been developed using Django (a Python-based framework) and PostgreSQL for the database layer. Celery (with a RabbitMQ message broker) is used for scheduled and triggered tasks. The client application is Dockerized, allowing it to run on any operating system that supports Docker Desktop. A custom CI pipeline automatically builds the client Docker images.
The DRAW Client can be deployed on any modern desktop operating system using Docker. Minimum system requirements are a 64-bit processor, at least 2GB of available RAM, and more than 10 GB of available hard disk space. It supports asynchronous task processing using Celery and also serves as a DICOM server using Pynetdicom. It supports two mechanisms for handling new DICOM data: a DICOM SCP (C-Store Service Class Provider) for automatic receiving, or a polling-based mechanism that watches a network directory for new files.
The DRAW API Server is deployed on a virtual private server with 2 vCPUs, 8 GB of RAM, and a 100 GB hard disk. It provides model provisioning services and task orchestration. It authenticates each DICOM transfer request using a client-specific access token stored encrypted at rest.
The Inference Pipeline is deployed on a VPS with 1 GPU (typically 8-12 GB of VRAM). An operating system template with all required packages is used. The DRAW client and API server are decoupled from the inference layer, meaning more advanced segmentation frameworks can be used in the future.
The DRAW client and server have been designed using similar software stacks to ease maintenance. The backends in both applications have been developed using Django (a Python-based framework) and PostgreSQL for the database layer. Celery (with a RabbitMQ message broker) is used for scheduled and triggered tasks. The client application is Dockerized, allowing it to run on any operating system that supports Docker Desktop. A custom CI pipeline automatically builds the client Docker images.
The DRAW Client can be deployed on any modern desktop operating system using Docker. Minimum system requirements are a 64-bit processor, at least 2GB of available RAM, and more than 10 GB of available hard disk space. It supports asynchronous task processing using Celery and also serves as a DICOM server using Pynetdicom. It supports two mechanisms for handling new DICOM data: a DICOM SCP (C-Store Service Class Provider) for automatic receiving, or a polling-based mechanism that watches a network directory for new files.
The DRAW API Server is deployed on a virtual private server with 2 vCPUs, 8 GB of RAM, and a 100 GB hard disk. It provides model provisioning services and task orchestration. It authenticates each DICOM transfer request using a client-specific access token stored encrypted at rest.
The Inference Pipeline is deployed on a VPS with 1 GPU (typically 8-12 GB of VRAM). An operating system template with all required packages is used. The DRAW client and API server are decoupled from the inference layer, meaning more advanced segmentation frameworks can be used in the future.
Data Flow
EXPORT WORKFLOW (client to server):
1. New DICOM data arrives at the configured central directory (via DICOM SCP or polling).
2. The client reads DICOM tag information to populate the database with patient, study, series, and instance data. Only CT, MR, and PET modalities are supported.
3. Based on configured rulesets, the client matches automatic segmentation templates to the DICOM data. If no match, processing terminates for that series.
4. De-identification is performed per HIPAA Safe Harbor standards. All patient identifiers are masked or replaced. Private tags are stripped.
5. A zip file is created with the DICOM data and segmentation templates. The SHA-256 checksum is calculated.
6. The client authenticates with the API using its access token and uploads the zip file. The server verifies integrity via SHA-256 and returns a unique task ID.
SERVER-SIDE PROCESSING:
7. The API server verifies the SHA-256 checksum and extracts the zip contents.
8. The YAML segmentation template is parsed; structures and models are stored in the database.
9. DICOM metadata is extracted and stored for the task.
10. A combined file (DICOM + YAML template) is sent to the remote GPU instance over a private network.
11. The ephemeral GPU instance runs nnU-Net v2 inference using the model information from the template.
12. Post-processing is applied: contour smoothing, removal of degenerate contours (3 or fewer points), handling of disconnected segments, and incorrect-side removal for lateralized structures.
13. The server downloads the RTStructureSet from the GPU instance and terminates the instance.
IMPORT WORKFLOW (server to client):
14. The client polls the upload status API at configured intervals (default 5 minutes). When status shows segmentation complete, it downloads the RTStructureSet.
15. The SHA-256 checksum is verified. The file is re-identified by matching the referenced series instance UID.
16. The re-identified file is sent to central datastore and optionally exported to the remote DICOM node.
17. The server is notified so remote files can be deleted. A housekeeping task removes files older than 7 days.
1. New DICOM data arrives at the configured central directory (via DICOM SCP or polling).
2. The client reads DICOM tag information to populate the database with patient, study, series, and instance data. Only CT, MR, and PET modalities are supported.
3. Based on configured rulesets, the client matches automatic segmentation templates to the DICOM data. If no match, processing terminates for that series.
4. De-identification is performed per HIPAA Safe Harbor standards. All patient identifiers are masked or replaced. Private tags are stripped.
5. A zip file is created with the DICOM data and segmentation templates. The SHA-256 checksum is calculated.
6. The client authenticates with the API using its access token and uploads the zip file. The server verifies integrity via SHA-256 and returns a unique task ID.
SERVER-SIDE PROCESSING:
7. The API server verifies the SHA-256 checksum and extracts the zip contents.
8. The YAML segmentation template is parsed; structures and models are stored in the database.
9. DICOM metadata is extracted and stored for the task.
10. A combined file (DICOM + YAML template) is sent to the remote GPU instance over a private network.
11. The ephemeral GPU instance runs nnU-Net v2 inference using the model information from the template.
12. Post-processing is applied: contour smoothing, removal of degenerate contours (3 or fewer points), handling of disconnected segments, and incorrect-side removal for lateralized structures.
13. The server downloads the RTStructureSet from the GPU instance and terminates the instance.
IMPORT WORKFLOW (server to client):
14. The client polls the upload status API at configured intervals (default 5 minutes). When status shows segmentation complete, it downloads the RTStructureSet.
15. The SHA-256 checksum is verified. The file is re-identified by matching the referenced series instance UID.
16. The re-identified file is sent to central datastore and optionally exported to the remote DICOM node.
17. The server is notified so remote files can be deleted. A housekeeping task removes files older than 7 days.
Privacy & Security
Patient privacy is a foundational design principle of DRAW.
All patient data is de-identified on the client side before transmission. The de-identification is performed in accordance with HIPAA Safe Harbor standards — all patient identifiers are masked or replaced by system-generated identifiers, and all private DICOM tags are stripped.
After the DRAW client downloads the RTStructureSet and re-identifies it by matching the referenced series instance UID, the API server deletes the de-identified images and RTStructureSet file after a successful transfer. Additionally, a dedicated server housekeeping task removes files older than 7 days from the storage.
The client-server communication uses authenticated connections with JSON Web Tokens (JWT). Each hospital client is issued a unique access token and refresh token. The access token is stored encrypted at rest on the client and can be refreshed at configured intervals. Token expiration is configurable per client.
All patient data is de-identified on the client side before transmission. The de-identification is performed in accordance with HIPAA Safe Harbor standards — all patient identifiers are masked or replaced by system-generated identifiers, and all private DICOM tags are stripped.
After the DRAW client downloads the RTStructureSet and re-identifies it by matching the referenced series instance UID, the API server deletes the de-identified images and RTStructureSet file after a successful transfer. Additionally, a dedicated server housekeeping task removes files older than 7 days from the storage.
The client-server communication uses authenticated connections with JSON Web Tokens (JWT). Each hospital client is issued a unique access token and refresh token. The access token is stored encrypted at rest on the client and can be refreshed at configured intervals. Token expiration is configurable per client.
Model Training & Provisioning
DRAW models are trained using the nnU-Net v2 framework, a self-configuring method for deep learning-based biomedical image segmentation that automatically configures the network architecture, preprocessing, and training pipeline for each specific dataset.
The DRAW API server is used to set up model configuration before training. This includes the model name, a unique three-digit ID, the model configuration, and the structures to be included. The model configuration can be exported as a YAML file and used alongside the CT data in the training pipeline.
Once a model has been trained and its performance validated on a local hold-out sample, the results folder is uploaded to the server. The server automatically extracts the key files containing the model weights and configuration, stores them on a shared network drive accessible by the ephemeral GPU instances, and marks the model as active. All DRAW clients can access information about active models via the API. Model versions can be updated without affecting downstream functionality — the latest version is always used when a client requests a model.
The system covers anatomical organs, clinical target volumes (both nodal and primary), and planning structures for treatment planning. Available models have been sequentially improved by retraining on larger samples. New models can be trained within one week if a curated dataset is available.
All delineations follow the TG-263 standard for nomenclature. Model performance metrics, data source, and guidelines for delineating the structures are publicly available on the DRAW website.
The DRAW API server is used to set up model configuration before training. This includes the model name, a unique three-digit ID, the model configuration, and the structures to be included. The model configuration can be exported as a YAML file and used alongside the CT data in the training pipeline.
Once a model has been trained and its performance validated on a local hold-out sample, the results folder is uploaded to the server. The server automatically extracts the key files containing the model weights and configuration, stores them on a shared network drive accessible by the ephemeral GPU instances, and marks the model as active. All DRAW clients can access information about active models via the API. Model versions can be updated without affecting downstream functionality — the latest version is always used when a client requests a model.
The system covers anatomical organs, clinical target volumes (both nodal and primary), and planning structures for treatment planning. Available models have been sequentially improved by retraining on larger samples. New models can be trained within one week if a curated dataset is available.
All delineations follow the TG-263 standard for nomenclature. Model performance metrics, data source, and guidelines for delineating the structures are publicly available on the DRAW website.
Segmentation Templates & Rulesets
Before any automatic segmentation can be started, users define automatic segmentation templates. Each template comprises a list of structures to be segmented. The system provides a wizard to create these templates, with information derived from the central server. During template creation, users can review the guidelines used to delineate a given structure in the training dataset, as well as the model accuracy metrics for that structure.
Rulesets define rules that the DRAW system uses to automatically process a DICOM dataset and associate it with a template. Each ruleset comprises rule groups containing individual rules combinable with AND/OR clauses. Users select the DICOM tag on which a rule is evaluated. The system provides guidance on the expected value type for a given DICOM tag and validates the provided value.
The DRAW client provides a "model mart" where users can pick and choose the models and structures they wish to be automatically segmented. As the number of models and structures increases, the DRAW system can flexibly accommodate multiple ways of delineating the same volume.
Rulesets define rules that the DRAW system uses to automatically process a DICOM dataset and associate it with a template. Each ruleset comprises rule groups containing individual rules combinable with AND/OR clauses. Users select the DICOM tag on which a rule is evaluated. The system provides guidance on the expected value type for a given DICOM tag and validates the provided value.
The DRAW client provides a "model mart" where users can pick and choose the models and structures they wish to be automatically segmented. As the number of models and structures increases, the DRAW system can flexibly accommodate multiple ways of delineating the same volume.
Post-Processing
When the system was initially developed, the contours were somewhat jagged, and small disconnected "blobs" were observed, with some structures sometimes segmented on the incorrect side.
All of these issues have been addressed by implementing a custom post-processing chain on the API server after inference. The retrieved RTStructureSet undergoes:
1. Contour smoothing — reduces jagged edges from the voxel-level segmentation.
2. Removal of degenerate contours — removes contours with three or fewer points.
3. Handling of disconnected contour segments — removes small disconnected "blobs" that are likely noise.
4. Handling of flipped contours on the opposite side — for lateralized structures (e.g. left kidney, right kidney), removes contours drawn on the incorrect side. The lateralized status of each structure is defined at the time of model creation in the DRAW API model provisioning system.
As nnU-Net is a semantic segmentation framework and region-based segmentation is not used, overlapping structures are trained in separate models so that during inference the overlapping nature is preserved.
All of these issues have been addressed by implementing a custom post-processing chain on the API server after inference. The retrieved RTStructureSet undergoes:
1. Contour smoothing — reduces jagged edges from the voxel-level segmentation.
2. Removal of degenerate contours — removes contours with three or fewer points.
3. Handling of disconnected contour segments — removes small disconnected "blobs" that are likely noise.
4. Handling of flipped contours on the opposite side — for lateralized structures (e.g. left kidney, right kidney), removes contours drawn on the incorrect side. The lateralized status of each structure is defined at the time of model creation in the DRAW API model provisioning system.
As nnU-Net is a semantic segmentation framework and region-based segmentation is not used, overlapping structures are trained in separate models so that during inference the overlapping nature is preserved.
Ready to get started?
Deploy DRAW at your institution — no local GPU hardware required.