DICOMweb maps imaging services onto familiar web patterns
DICOMweb exposes search, retrieve, and store behaviors over HTTP so web viewers, mobile apps, and cloud services can interact with imaging archives without speaking DIMSE directly.
The important architectural point is that DICOMweb does not abandon DICOM semantics. It repackages them into web-friendly resource paths, media types, and JSON or multipart exchanges.
Browser-safe DICOM access pattern
Loading diagram...
DICOM Part 18: Web services
Official DICOMweb reference for RESTful access patterns, media types, and web-service behavior.
Read Part 18AWS HealthImaging DICOMweb guide
Official AWS documentation for using DICOMweb against AWS HealthImaging imaging stores.
Read the AWS DICOMweb guideQIDO-RS, WADO-RS, and STOW-RS split search, retrieve, and store
DICOMweb deliberately separates search, retrieve, and store responsibilities. That separation helps architects put the right caches, auth policies, and rate limits in front of each behavior instead of treating imaging access as one monolithic operation.
DICOMweb service examples
Representative QIDO-RS, WADO-RS, and STOW-RS calls showing how modern clients interact with imaging services over HTTP.
Request
GETANNOTATIONS
Response
In production, viewers rarely jump straight from search to full native-object retrieval for every click. They usually query first, fetch enough metadata to build the navigation model, and only then request either rendered output or native frames depending on the workflow and client capability.
Metadata-first viewer retrieval path
Loading diagram...
DICOMweb services in Part 18
Normative DICOMweb definitions for QIDO-RS, WADO-RS, and STOW-RS.
Review the service definitionsAWS HealthImaging DICOM reference
Official AWS documentation describing DICOM support expectations for HealthImaging.
Read the AWS DICOM referenceAccept headers and retrieve targets change the payload you actually get
DICOMweb retrieval is not one generic download endpoint. Part 18 keeps metadata, native DICOM retrieval, rendered media retrieval, frame retrieval, and bulk-data access separate so clients can ask for the minimum shape they need instead of always pulling a full object.
Selected instance to response-shape decision
Loading diagram...
Why DICOMweb keeps retrieve paths distinct
| Retrieve goal | Typical request shape | Why it stays separate |
|---|---|---|
| Metadata navigation | QIDO-RS or metadata-focused WADO-RS transaction | Lets a viewer build study trees and hanging protocols without pulling pixel data too early. |
| Native diagnostic retrieval | Accept: application/dicom | Preserves original object semantics, including transfer-syntax and decoder responsibilities. |
| Browser-safe preview | Rendered image or video media type | Simplifies display but intentionally trades away some native pixel semantics. |
| Selective heavy-payload access | RetrieveFrames or bulk-data dereference | Avoids dragging full-object payloads through every interaction path. |
Rendered media is not transfer-syntax negotiation by another name
Part 18 treats rendered media types as their own path and says the transfer-syntax media-type parameter is not used there. That means a browser preview cache should not be mistaken for a native-object cache.
This distinction is not just theoretical. Managed services and viewer gateways often phase in DICOMweb features over time. AWS HealthImaging release notes, for example, document when RetrieveFrames support and the DICOM JSON model became available, which is exactly the sort of service-level detail teams should verify before they assume a web viewer can use every retrieval pattern they teach on paper.
DICOM Part 18 retrieve transactions
Current DICOMweb chapter defining the retrieve families and request/response behavior in Part 18.
Review the retrieve transactionsDICOM Part 18 rendered media types
Specific DICOMweb rule stating how rendered media types behave and why transfer-syntax parameters do not apply there.
Read the rendered-media rulesAWS HealthImaging release notes
Service-level feature history that helps teams confirm whether DICOMweb capabilities such as RetrieveFrames or the DICOM JSON model are available in the managed archive they plan to use.
Review DICOMweb feature availabilityModern viewers still need an imaging-aware gateway
DICOMweb makes browser access possible, but production deployments still need policy decisions around authentication, CORS, audit, caching, and bulk-data dereferencing. That usually means an imaging-aware gateway rather than direct anonymous access from the browser to the archive.
Retrieval choices that DICOMweb keeps distinct
| Need | Typical response shape | Architectural consequence |
|---|---|---|
| Metadata navigation | DICOM JSON metadata | Good for search results, hanging protocols, and viewer-side study trees without pulling pixel data early. |
| Native diagnostic retrieval | application/dicom or native frame payloads | Preserves original object semantics but keeps decoder and transfer-syntax obligations on the consumer path. |
| Browser preview | Rendered image or video media type | Simplifies web display but may remove native pixel semantics that advanced tools still need. |
| Deferred large payload access | Bulk-data URI or bulk-data response | Lets gateways and analytics pipelines fetch heavy pixel content separately from metadata. |
QIDO-style metadata response
A simplified DICOM JSON metadata payload showing how web clients still receive DICOM tags and VR-driven values.
Click on an annotation to highlight it in the JSON
Web-native does not mean semantics-free
A browser client still has to understand study, series, instance, transfer-syntax, and media-type implications. DICOMweb modernizes transport, not the domain model.
The Accept header and chosen transaction decide whether the client gets a native DICOM object, metadata-only JSON, a rendered preview, or dereferenceable bulk data. That means frontend and gateway design still have to be explicit about caching, decoder placement, and downstream audit expectations.
DICOM Part 18 JSON model
Official reference for how DICOM attributes are represented in JSON over web services.
Review the JSON representationUsing DICOMweb with AWS HealthImaging
AWS guide covering DICOMweb usage patterns for search and retrieval in a managed imaging service.
Read the usage guideDICOM Part 18: Media type rules
Specific DICOMweb media-type definitions for native, rendered, and bulk-data oriented retrieval behavior.
Review media-type behaviorKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.