Orthanc DICOMweb integration

Most teams need to know one thing first: which DICOMweb service handles which job, and which direction of the integration they are building. In DICOMweb, QIDO-RS handles search, WADO-RS handles retrieval and STOW-RS handles storage. Each is a set of RESTful HTTP endpoints that operate on DICOM studies, series and instances, so a client can find, fetch and send imaging data without speaking classic DICOM networking (the C-FIND, C-MOVE and C-STORE protocol). In Orthanc, the official DICOMweb plugin is what exposes these endpoints. The Orthanc plugins list includes DICOMweb alongside the database, object storage, worklist and viewer plugins, so it is an officially maintained extension rather than a third-party add-on.

A viewer or AI tool uses the three services in a predictable sequence. It first queries with QIDO-RS to list patients, studies or series that match criteria such as date, modality or accession number. It then retrieves the pixel and metadata payloads it needs with WADO-RS, often a single instance or frame at a time for a responsive display. A storage or analysis pipeline uses STOW-RS to push results back, such as a structured report, a segmentation or a derived image, so the output lands next to the source study. The practical question for the design is which of these calls the client needs, because a read-only viewer may only need search and retrieval, while an AI workflow that writes results needs storage as well.

The integration runs in two directions, and the first decision is which one applies. In the first direction, Orthanc acts as the DICOMweb server: the plugin publishes its stored studies to clients such as browsers, research tools or partner systems over HTTP. Here the work centers on what is exposed, which users can reach it, and whether the endpoints sit behind HTTPS and a reverse proxy. In the second direction, Orthanc acts as a DICOMweb client of a remote server, such as a cloud archive or another hospital's vendor-neutral archive. Orthanc then queries, retrieves or stores against that remote endpoint. Many sites run both at once, so they should map each dataflow to a direction before configuring anything.

Access control deserves early attention because the DICOMweb endpoints are HTTP routes. Orthanc's security guidance says that by default it only accepts HTTP from localhost, and that remote access should be paired with authentication, registered users and HTTPS. The documentation also warns that routes such as the script execution and export routes should stay disabled. For a DICOMweb deployment, confirm which roles may call QIDO-RS, WADO-RS and STOW-RS separately, because a write-capable STOW-RS client has a different risk profile from a read-only search client. The advanced authorization plugin can forward each request's token to an external service for that decision, which is worth evaluating if your identity model is already centralized.

Ask your team to confirm three things before design starts: the list of clients and the calls each one needs, the remote DICOMweb endpoints Orthanc must reach and the network paths and certificates they require, and the access model for read and write calls. The OHIF viewer and its data source options are covered in the sibling topic on Orthanc with the OHIF viewer, so this section stops at the protocol mapping. Check the current plugin documentation for the exact endpoint behavior and supported options in the Orthanc version you plan to run, because the DICOMweb plugin is versioned separately from the core server.

Before an Orthanc DICOMweb endpoint serves a clinical or research client, the team should run one written test plan that proves every client can query, retrieve and store against a controlled dataset, that the endpoint refuses what it should refuse, and that it holds up at the expected study count. Each client is a separate test subject. The viewer, the AI tool and the cloud archive each send different request patterns, so passing with one client does not show the others will work. Start by listing every real client, the DICOMweb services it uses (QIDO-RS, WADO-RS, STOW-RS), the authentication method it presents and the network path it takes to reach Orthanc.

Functional tests per client. Build a test dataset that mirrors production content: several patients, multiple studies per patient, series with different modalities, and instances with the transfer syntaxes your clients actually request. Run queries with the search parameters each client uses, retrieve studies, series and instances in the formats each client accepts, and store test objects through STOW-RS. Record the exact request, the HTTP response and whether the object appears in Orthanc Explorer 2 or the database index. For the viewer, the OHIF sibling topic covers the browser-side checks in more depth, so this plan only confirms the viewer can complete its basic query and retrieve path.

Negative tests. These carry most of the security evidence. Send unauthenticated requests to every DICOMweb route and confirm each one is rejected. Send requests from a host outside the allowed network to confirm the access path is blocked at the proxy or firewall, not just in the application. Confirm that remote access settings match the documented expectation: if RemoteAccessAllowed is enabled, AuthenticationEnabled should be true and only the users defined in RegisteredUsers should authenticate. Attempt STOW-RS uploads of unsupported content, such as files that are not valid DICOM, and confirm they are rejected without leaving partial objects in the index. Also confirm that the /tools/execute-script and export routes are disabled, as the Orthanc security FAQ advises.

Load and volume checks. Size the test to the study count the endpoint must hold at go-live and at the planned growth point, not to an arbitrary number. Ask the platform owner for the expected study and instance counts, the peak concurrent client count and the largest expected study size, then load a dataset of that shape. Measure query latency, retrieval throughput and store behavior under concurrent use, and watch memory and storage I/O. If the expected volume approaches the range where the built-in SQLite index is no longer appropriate, the scalability FAQ recommends evaluating the PostgreSQL plugin before go-live rather than after. Confirm the target volumes with the team that owns the clinical or research workload, because the test is only as good as those numbers.

Acceptance evidence for the change record. Keep a single package that includes the test plan with its version, the dataset description and hash, the Orthanc version and plugin versions under test, the configuration files with secrets removed, the request logs for each test case with pass or fail results, the load test reports, and the sign-off from each client owner. Record any accepted deviations with a named owner and a review date. Retain the package with the change ticket so auditors and future upgrade teams can see what was proven and under which configuration. Repeat the negative and per-client tests after every Orthanc upgrade, since the release notes for 1.13.0 describe changes to storage access and DICOM parsing that can affect client behavior.