DICOMweb is well-specified. The DICOM standard's web services — STOW-RS for storing instances, WADO-RS for retrieving them, and QIDO-RS for querying — have been part of the standard since the DICOMweb supplement was formally incorporated. The specification is clear. Implementations, unfortunately, are not. Every PACS vendor implements DICOMweb with slightly different behavior, slightly different header requirements, and slightly different interpretations of edge cases in the standard. When you connect an AI pre-reading system to a PACS via DICOMweb, those differences surface immediately.
After working through DICOMweb integration with several imaging centers that run different PACS platforms, we have started to recognize patterns in where things go wrong. This post describes the mistakes we have seen most often — not as a comprehensive integration guide, but as a heads-up for IT administrators and PACS admins who are about to go through this process.
Mistake 1: Assuming STOW-RS Is Bidirectional by Default
The most common misconception we encounter is that configuring STOW-RS routing from the PACS to Histolyx automatically means Histolyx can write annotation data back to the same PACS. It does not. Inbound STOW-RS (studies flowing from PACS to AI) and outbound STOW-RS (annotations flowing from AI back to PACS) are separate configurations, and the PACS vendor's implementation often handles them differently.
On the inbound side, the PACS pushes studies via STOW-RS to Histolyx's endpoint. That is configured in the PACS's routing rules: a rule that says "for studies matching these criteria (modality, body part, priority), POST to this URL." Straightforward in principle, variable in practice because PACS vendors differ on: whether they require mutual TLS for STOW-RS endpoints, how they handle large multi-frame studies that exceed default payload size limits, and whether they respect the standard's multipart/related content type for the STOW-RS request body.
On the outbound side — Histolyx writing annotation objects back to the PACS — the configuration typically requires a separate STOW-RS endpoint defined in the PACS for external stores, and may require the PACS to support DICOM structured reporting objects or DICOM presentation states depending on how annotations are represented. Some PACS implementations accept GSPS (Grayscale Softcopy Presentation State) for annotation overlay. Others expect DICOM SR (Structured Report). Others have proprietary annotation formats that bypass standard object types entirely.
Before go-live, confirm: what DICOM object types does your PACS accept for AI-generated annotations? That answer determines the annotation format Histolyx needs to produce, and it is not something to discover after you have finished configuring routing.
Mistake 2: Testing on a Data Sample That Doesn't Represent Production
Integration testing with five to ten sample studies is common. It is also frequently insufficient. The failure modes we have seen in production integrations are almost never triggered by simple, well-formed studies. They appear with: studies that have non-standard character encoding in patient name fields (DICOM specifies LO value representation but real PACS implementations vary in how they handle extended character sets), studies acquired on older scanner firmware that produces non-conformant transfer syntaxes, multi-series studies with unusual series numbering or missing mandatory tags, and very large CT studies with high-resolution reconstruction that hit network timeout limits on the STOW-RS POST.
The testing sample that matters is not a clean sample — it is a representative sample drawn from your actual worklist over a two- to four-week period, including edge cases. For an imaging center doing 200+ studies daily, that means at minimum 50-100 studies in the test set, including studies from older scanner models, pediatric studies, studies with any non-standard acquisition parameters, and studies where the PACS has known metadata quirks.
We now ask all new customers to provide their last 100 studies from the target modality before go-live, de-identified per 45 CFR 164.514 Safe Harbor method. Running those through the integration before it is live in production catches the majority of format-handling issues before they affect clinical workflow.
Mistake 3: No Monitoring on Study Flow Volume
This is the mistake that causes the most operational problems after go-live, and it is entirely preventable. DICOMweb integrations break silently. A routing rule misconfiguration, a PACS software update that changes how routing rules are applied, a firewall rule change, a certificate expiry on a mutual TLS endpoint — any of these can stop studies from reaching Histolyx without producing an error message visible to anyone in the radiology department. The first sign of a broken integration is often a radiologist noticing that annotations are missing from studies. By that point, how many studies have been read without pre-screening?
The mitigation is a monitoring layer on both sides. On Histolyx's side, we track inbound study volume per customer and alert when volume drops below a configured baseline for a given time window. If an imaging center typically sends 200 studies per day and that drops to zero, we flag it within an hour. On the customer's side, the PACS admin should have a monitoring view that shows outbound routing rule activity — studies sent, studies failed, studies queued. Not all PACS platforms expose this in an accessible way, but most have some form of routing audit log.
The configuration we recommend is a two-layer alerting setup: Histolyx's monitoring as a first tier (since we see the incoming volume directly), plus a PACS-side daily volume check that the PACS admin or IT team reviews. The overlap is intentional — if one layer misses a failure, the other catches it.
QIDO-RS for Worklist Integration: When It Helps and When It Adds Complexity
QIDO-RS — the query portion of DICOMweb — allows external systems to query the PACS for study metadata without retrieving pixel data. For AI pre-reading, QIDO-RS is useful if you want Histolyx to proactively query for pending studies and process them in advance rather than waiting for the PACS to push studies via STOW-RS. The push model (PACS → STOW-RS → AI) is simpler to configure and works well when study volume is predictable. The pull model (AI → QIDO-RS → PACS) adds flexibility but also adds a query relationship that the PACS admin needs to configure and secure.
For most imaging centers we work with, the push model via STOW-RS is the right default. It maps to how the PACS already handles routing to remote stores, it does not require Histolyx to have query privileges on the PACS, and it produces lower latency for individual studies because processing starts immediately on receipt rather than waiting for a query cycle. The pull model makes sense for specific scenarios: very high study volume where batch processing is more efficient, sites that want to process historical studies without re-sending them, or deployments where the PACS does not support STOW-RS routing (older PACS generations sometimes support only DIMSE, in which case a gateway layer is required).
Transfer Syntax Negotiation
DICOM pixel data is encoded in a transfer syntax that specifies compression type and byte order. The most common are Explicit VR Little Endian (uncompressed), JPEG Lossless, JPEG Baseline (used for some X-ray/DR studies), and JPEG 2000. Modern CT and MR studies are often stored as Explicit VR Little Endian or JPEG Lossless. Mammography is more variable.
When the PACS pushes a study to an external endpoint via STOW-RS, it typically sends it in the storage transfer syntax — the encoding used internally. If Histolyx's inference pipeline expects a different encoding, the receiving end needs to transcode. We handle transcoding on our side for all standard DICOM transfer syntaxes, but there is a performance cost for lossless decompression of very large studies at volume.
Where this becomes a problem: some older PACS implementations push studies in legacy transfer syntaxes that are valid DICOM but uncommon enough that off-the-shelf DICOM toolkits have inconsistent support. If your PACS is more than ten years old, ask your PACS vendor which transfer syntaxes it uses for STOW-RS pushes, and confirm that your AI vendor's ingestion pipeline handles those syntaxes. Do this before signing a contract, not after.
A Pre-Go-Live Checklist
Based on the above, the integration verification steps we run before declaring an imaging center live:
Confirm PACS supports STOW-RS to external endpoints and that routing rules can be scoped by modality and study type. Verify the annotation return path — what DICOM object type the PACS accepts for AI annotations and whether a test annotation object displays correctly in the reading room viewer. Run 50–100 representative studies through the integration in a staging environment, including studies with non-standard metadata. Confirm monitoring is in place on both sides, with alerting that fires within one hour of anomalous volume. Document the firewall rules and TLS certificate details so that future network changes can be made without breaking the integration. Establish a contact name on the PACS admin team who can be reached if a routing issue needs same-day diagnosis.
None of this is exotic. It is the same project management rigor that any complex integration requires. The reason we are writing it down is that imaging center IT teams are often running lean, the urgency to go live creates pressure to skip pre-production testing, and the failure modes for DICOMweb integrations are non-obvious enough that the problems tend to appear in production rather than in testing — which is exactly where you do not want them.