DICOM and interoperability planning in digital pathology

Interoperability in digital pathology is a planning problem before it is an interface problem. A useful design starts with the information that must move, the systems that own it, the identifiers that connect it, and the people responsible when a transfer is delayed or incomplete. DICOM provides important building blocks, but conformance does not make every workflow interchangeable.

Map the information model first

Whole-slide microscopy uses large tiled pixel matrices and associated study, series, specimen, equipment, optical path, and spatial information. Before selecting an endpoint, document which attributes are required for review, analysis, reporting, archival, and traceability. Decide how specimen and case identifiers are created, preserved, reconciled, and protected across each boundary.

Separate storage, query, retrieve, and result flows

• DICOM storage describes how instances are sent and received, while DICOMweb services expose distinct store, query, and retrieve interactions.
• WADO-RS, STOW-RS, and QIDO-RS have different responsibilities and should not be treated as one generic integration.
• Annotations, measurements, derived images, and reports need an agreed representation and relationship to the source study.
• A conformance statement should be read alongside real examples, limits, transfer syntax support, and error behavior.

A workflow diagram should show direction, timing, ownership, retries, and what happens when a transfer succeeds technically but fails operationally. For example, a stored image may be available while metadata reconciliation, worklist state, or a derived result remains incomplete. Those states need names and handling rules that users can understand.

Plan the laboratory and archive boundaries

A laboratory information system, an image archive, a scanner, a viewer, and an analytics service may each have different ownership and retention expectations. Interoperability planning should identify the system of record, permitted data paths, identity and access controls, audit requirements, retention periods, and the escalation owner for each boundary. This article does not assume that any particular product integrates with an LIS or PACS.

Testing should include large and sparse slides, missing or unexpected metadata, duplicate identifiers, partial transfers, unsupported transfer syntaxes, interrupted retrieval, retries, timeouts, and access failures. Validate both machine behavior and the user's resulting task. A technically valid exchange can still create an unsafe or confusing workflow if the wrong case is displayed or a failure is silent.

The durable lesson is to treat standards as a shared vocabulary, not as a turnkey deployment plan. A clear information model, explicit conformance expectations, realistic test data, and named operational ownership make interoperability easier to evaluate without promising that two systems will connect automatically.