DICOMweb

QIDO-RS (Query based on ID for DICOM Objects using RESTful Services) is the search mechanism of DICOMweb. It allows a client to query an archive for studies, series, or instances matching specific criteria.

• Method: HTTP GET
• Query Parameters: Patient Name, Modality, Study Date, Accession Number
• Response: JSON or XML payload containing matching DICOM metadata
• Use Case: An edge AI device queries the PACS to find all unread chest X-rays from the last 24 hours to batch-process through a diagnostic model.

WADO-RS (Web Access to DICOM Persistent Objects using RESTful Services) is the standard for retrieving individual DICOM instances or frames. Unlike the older WADO-URI, it uses RESTful URLs for clean, cacheable access.

• Retrieve a full instance: GET /studies/{study}/series/{series}/instances/{instance}
• Retrieve a single frame: Append /frames/{frame} for multi-frame objects like cine loops
• Bulk retrieval: Supports multipart/related content-type for efficient batch downloads
• Edge Integration: A scanner-side AI retrieves a specific CT series for real-time reconstruction without downloading the entire study.

WADO-URI (Web Access to DICOM Persistent Objects by URI) is the legacy predecessor to WADO-RS. It uses query-string parameters in a single HTTP GET request to fetch a specific DICOM object.

• Key Parameters: requestType=WADO, studyUID, seriesUID, objectUID
• Content Negotiation: Returns the object as application/dicom or renders it as JPEG, PNG, or other consumer formats
• Limitation: Stateless and non-cacheable; lacks the RESTful resource hierarchy of WADO-RS
• Relevance: Still widely supported in legacy PACS, but DICOMweb-compliant systems should prefer WADO-RS for new integrations.

STOW-RS (Store Over the Web using RESTful Services) is the mechanism for uploading DICOM instances to a server. This is the critical service that allows an edge AI pipeline to write its results back to the archive.

• Method: HTTP POST
• Endpoint: /studies or /studies/{study}
• Payload: Multipart/related body containing one or more DICOM instances
• AI Output Workflow: After a diagnostic model generates a Secondary Capture or Structured Report with AI findings, STOW-RS stores it as a new series within the original study, making it immediately visible to radiologists.

UPS-RS (Unified Procedure Step using RESTful Services) manages worklists and tracks the status of scheduled tasks. It is the orchestration layer for DICOMweb-based workflows.

• Create Workitems: An AI orchestrator creates a workitem for a specific diagnostic task (e.g., 'Run lung nodule detection on Study X')
• Claim and Complete: An edge inference engine claims the workitem, processes it, and marks it as COMPLETED or CANCELED
• Subscription Model: Clients can subscribe to receive push notifications on workitem state changes
• Value: Enables a robust, asynchronous, and auditable pipeline where multiple AI services can coordinate without a monolithic controller.

DICOMweb mandates support for representing DICOM metadata as JSON or XML, a radical departure from the binary DICOM Part 10 format. This makes metadata accessible to any modern web application.

• Content-Type: application/dicom+json
• Structure: A flat array of objects, each with a vr (Value Representation) and Value key
• Bulk Data URIs: Large binary attributes like pixel data are not embedded; instead, a BulkDataURI is provided for separate retrieval via WADO-RS
• Developer Impact: Eliminates the need for a DICOM parsing library. A simple JavaScript fetch() call can read patient demographics, study descriptions, and AI-generated structured report findings.

The RESTful service for transmitting DICOM objects to a server via HTTP POST. This is the primary mechanism for edge AI devices to push structured reports, secondary captures, and parametric maps into a PACS or VNA.

• Uses multipart/related media type for efficient binary transfer
• Supports bulk upload of multiple SOP instances in a single transaction
• Enables scanner-side AI to persist results without DIMSE C-STORE negotiation