DICOMweb
Routes speaks DICOMweb both ways: it sends to cloud PACS, VNAs and AI services, and serves uploads, searches and retrievals on each node’s DICOMweb port.
Sending (STOW-RS)
Section titled “Sending (STOW-RS)”A DICOMweb destination posts instances to {service root}/studies. Configuration › Destinations › Add
destination, kind DICOMweb.
Signing in
Section titled “Signing in”| Authentication | For |
|---|---|
| None | A service on a trusted network. |
| User name and password (Basic) | Most on-premises services. |
| Fixed bearer token | Services that issue long-lived tokens. |
| OAuth 2.0 client credentials | Azure Health Data Services, and other OAuth services. |
| Google Cloud service account | Google Cloud Healthcare API. |
- Azure: the service URL is
https://….dicom.azurehealthcareapis.com/v2; register an application, give it the DICOM Data Owner role on the DICOM service, and use its client ID and secret. Fill in for Azure sets the token endpoint for your tenant and the scope. - Google Cloud: the URL is
https://healthcare.googleapis.com/v1/projects/…/locations/…/datasets/…/dicomStores/…/dicomWeb; create a service account with the Healthcare DICOM Editor role on the store, and paste its JSON key (checked when saved). - Tokens are reused until shortly before they expire. Secrets are stored encrypted, never shown again or exported, and only sent over HTTPS.
Sending
Section titled “Sending”- Up to instances per request (default 10, about 64 MB) of what is waiting go in one request, with several requests per node in parallel: far fewer round trips to a distant service. Each instance gets its own outcome.
- Queues, retries, priorities, schedules, bandwidth limits, tag edits, de-identification and dead letters work as for DICOM destinations.
- The transfer syntax list applies: if the service refuses a syntax, the next is tried.
- Refused credentials, a wrong URL or no connection make the destination unreachable (its queue waits). Retryable answers back off; other refusals are dead-lettered with the service’s reason.
- An instance the service already holds counts as delivered, with a note: it was sent before, by a resend or a request that timed out after the service stored it.
- Check (instead of Echo) searches for one study with the credentials.
Receiving uploads (STOW-RS)
Section titled “Receiving uploads (STOW-RS)”Systems that send over HTTPS rather than DICOM (AI results, web apps, cloud archives) can upload to every node:
- Set a DICOMweb port in Settings (8443, say). Nodes serve it with their TLS certificate.
- On a source, tick Accept DICOMweb uploads from these senders and add each sender by name. Each gets its own token, shown once.
- Give the sender the address
https://<node>:8443/dicomweb/studiesand its token (as a Bearer token, or the password of Basic authentication).
Uploaded instances go through the same routing as DICOM ones. The answer is the standard DICOM JSON list of stored and failed instances: 200 when all were stored, 202 when some failed, 409 when none were.
Search and retrieve (QIDO-RS and WADO-RS)
Section titled “Search and retrieve (QIDO-RS and WADO-RS)”Web viewers such as OHIF search and display studies through the router, from the archives, when their source allows query/retrieve:
- QIDO-RS:
/dicomweb/studies,/studies/{study}/series,…/instances, with keywords or tags as parameters. - WADO-RS: studies, series, instances and their metadata; frames, uncompressed or compressed as the viewer asks.
- Rendered images and thumbnails: JPEG, PNG or animated GIF, with windowing, overlays, shutters, and presentation states (annotations, rotation, PET over CT blending).
- Instances stream to the viewer as they arrive from the archive, and are kept on the node briefly (30 minutes by default) so a viewer’s follow-up requests are answered from the copy.
- Browsers on the origins listed in Settings may call these endpoints (CORS).
Users signed in through an identity provider
Section titled “Users signed in through an identity provider”With Settings › DICOMweb sign-in set (the provider’s issuer and audience), nodes accept the access token of a user signed in to a web viewer. Each source lists the groups or roles whose users act as its senders. The audit log names the user. For OHIF, configure its OpenID Connect sign-in with the same provider and point its data source at a node.
Limits
Section titled “Limits”Per sender, at most 32 requests at once and 6,000 a minute; per address, 20 failed sign-ins in 5 minutes lock it out for 5 minutes. The largest request is 10 GB by default, written to disk as it arrives. All are adjustable in Settings.