When we start a conversation with an imaging center IT director about integrating Histolyx, the first question is almost always the same: "Does it work with our PACS?" The honest answer is "it depends on which DICOMweb services your PACS exposes and how." That answer requires some explanation, so here's a plain-language breakdown of what DICOMweb actually is, what the individual services mean, and what questions to ask before assuming compatibility.
This isn't a comprehensive DICOMweb specification guide — those exist and are quite long. This is a practical orientation for IT directors who need to evaluate vendor claims and make configuration decisions without necessarily having a DICOM background.
Legacy DICOM Versus DICOMweb: The Core Distinction
Traditional DICOM communication — the kind that most PACS installations have been using for twenty-plus years — uses DIMSE (DICOM Message Service Element) over a persistent TCP/IP connection. DIMSE services like C-STORE (push a study to another device) and C-FIND (query a remote archive) require both endpoints to speak DICOM natively, maintain a persistent "association" during the exchange, and be configured with AE Titles that must match on both sides.
DIMSE works reliably in controlled hospital networks where all the imaging devices are known, trusted, and configured in advance. It becomes awkward when you need to route studies to an external service over the public internet, or when the receiving endpoint is a cloud-based application that doesn't want to run a persistent DICOM listener. Setup requires bidirectional configuration — you configure your PACS with the remote AE Title and IP, and the remote system configures your AE Title. When something breaks, the debugging is opaque.
DICOMweb is a set of RESTful HTTP-based services that accomplish the same tasks — retrieve images, store images, query study metadata — using standard web protocols. Because it's HTTP, it works across firewalls, through TLS for encryption, and doesn't require persistent connections or AE Title configuration. A PACS that exposes a DICOMweb endpoint looks, from the network perspective, like any other HTTPS API.
The Three DICOMweb Services You Need to Know
DICOMweb is defined by IHE (Integrating the Healthcare Enterprise) and DICOM itself as a family of three services. Each does a different job.
WADO-RS — Web Access to DICOM Objects, RESTful
WADO-RS is the retrieval service. Given a study UID, series UID, or instance UID, WADO-RS returns the actual DICOM pixel data and metadata. This is the service an AI analysis tool uses to fetch imaging data after it's been notified a study is ready. An AI pre-reader like Histolyx uses WADO-RS to pull the full study for analysis once it's been triggered by a new study notification.
The key WADO-RS endpoints follow this pattern: /wado/rs/studies/{studyUID}/series/{seriesUID}/instances. The response is multipart MIME containing the DICOM instances. The critical compatibility question for WADO-RS is whether your PACS requires authentication (bearer token, basic auth, or certificates) on the WADO-RS endpoint, and whether it supports bulk data retrieval or only single-instance requests.
STOW-RS — Store Over the Web, RESTful
STOW-RS is the storage service — the reverse of WADO-RS. A client sends DICOM instances to a STOW-RS endpoint and they are stored in the receiving archive. An AI pre-reader uses STOW-RS to push annotation results back to the PACS: the structured report (a DICOM SR object), any annotation overlays (DICOM Presentation State or structured report objects), or secondary capture images with findings marked.
The common compatibility issue with STOW-RS is that PACS vendors differ on what object types they accept via STOW-RS. A PACS might accept STOW-RS for standard image instances but reject DICOM SR (Structured Report) objects, or accept SR objects but not certain SR templates. Before assuming that Histolyx's output will route back into your PACS correctly, you need to know what SOP classes your PACS accepts via STOW-RS.
QIDO-RS — Query Based on ID for DICOM Objects, RESTful
QIDO-RS is the query service. It lets you search a PACS archive for studies, series, or instances that match specified criteria — patient ID, study date, modality, accession number — and returns metadata (not pixel data) matching the query. An AI orchestration system might use QIDO-RS to poll for new studies of a particular modality, or to verify that a study has been stored completely before triggering analysis.
QIDO-RS is often the service that PACS vendors implement most variably. The spec allows a wide range of query parameters, and many PACS products implement only a subset. A QIDO-RS endpoint that doesn't support StudyDate range queries, for instance, makes automated worklist polling significantly harder.
What "DICOMweb Compatible" Actually Means in a Vendor Claim
When an AI vendor says their product integrates via DICOMweb, that claim can mean many things. At minimum it means they can communicate via HTTP/HTTPS with a DICOMweb endpoint. It says nothing about which services they use, which SOP classes they support for STOW-RS, or how they handle authentication. It also doesn't tell you whether they've tested against your specific PACS version.
The questions worth asking a vendor before assuming integration will be straightforward:
Which DICOMweb services do you use, and in which direction? (WADO-RS to retrieve, STOW-RS to push results back, QIDO-RS to discover studies?) What SOP classes do you send via STOW-RS — DICOM SR, DICOM Presentation State, secondary capture images? What authentication methods do you support on the WADO-RS endpoint? Do you support OAuth2 bearer tokens, client certificates, or basic auth over TLS? Do you have documented experience with our PACS vendor and version?
That last question is important. DICOMweb compliance at the protocol level doesn't guarantee that vendor A's implementation and vendor B's implementation will talk to each other without friction. Edge cases in multipart MIME encoding, differences in how study UIDs are formatted in URL paths, and variations in the metadata returned by QIDO-RS can all cause integration failures that look like connectivity problems but are actually implementation differences.
The DICOM Routing Architecture Question
Beyond DICOMweb API compatibility, there's a network architecture question that often matters more for operational reliability: where does the AI tool sit in the study flow, and what triggers it?
There are two common patterns. In the first, studies flow from the modality to the PACS normally, and a separate notification mechanism (an HL7 message, a DICOM worklist event, or a QIDO-RS poll) tells the AI tool that a new study is ready for analysis. The AI then fetches the study via WADO-RS. This pattern keeps the normal study flow intact — the PACS receives studies as always — and the AI operates as a downstream consumer.
In the second pattern, studies are routed to the AI tool before or in parallel with routing to the PACS. This is architecturally simpler in some ways but introduces the AI tool into the critical study delivery path. If the AI tool has a service outage, it can affect study availability in the PACS — which is generally a problem you want to avoid.
We designed Histolyx to operate in the first pattern — downstream from the PACS, triggered by notification, fetching via WADO-RS, pushing results back via STOW-RS. This keeps the PACS as the authoritative archive and the study delivery system, and Histolyx as an analysis service that adds to what's there rather than being in the critical path for what arrives.
Practical Pre-Integration Checklist
Before starting any DICOMweb integration project, the information you want in hand is: your PACS vendor and version, which DICOMweb services your PACS exposes (WADO-RS, STOW-RS, QIDO-RS — and which version of each, since the spec has evolved), what SOP classes your PACS accepts via STOW-RS, what authentication mechanism protects your DICOMweb endpoints, and whether your PACS is cloud-hosted or on-premise (this affects network routing and firewall rules significantly).
With that information, a vendor who actually has documented DICOMweb integration experience should be able to tell you quickly whether a straightforward integration is likely or whether there are known compatibility issues to work through. "We support DICOMweb" without specifics is a reason to ask more questions, not a reason to stop asking them.