DICOM Whole Slide Imaging Integration: Scanner to AI Guide

DICOM (Digital Imaging and Communications in Medicine) whole slide imaging (WSI) integration is a systems-engineering problem more than a file-format choice. The standard stores each pyramid level of a scanned slide as a tiled, multi-frame image object, with tiles as frames (^[1]). It carries specimen and container identity inside the image object (^[2]). Retrieval runs over DICOMweb, and annotations and AI outputs travel as separate objects. The practical question for pathology IT teams is therefore how to get slide identity from the laboratory information system (LIS) to the scanner, and how to get tiles, annotations and model results back to viewers, without losing either.

Three paths exist. A native DICOM path has the scanner emit WSI instances directly; vendors document this as an option or a default on some current devices (^[3]) (^[4]). A dual-personality or conversion path rewrites proprietary files, and Microsoft's Azure documentation states plainly that a format conversion is required for WSI in other formats (^[5]). A proprietary path keeps vendor formats and viewers, and the literature observes that manufacturers, developers and users continue to depend on such formats (^[6]). Most enterprises will run a mixture during migration, so DICOM should be the system of record and conversion a testable stage.

The identity chain is the least forgiving part. The IHE (Integrating the Healthcare Enterprise) Digital Pathology Image Acquisition (DPIA) supplement, published for trial implementation on March 6, 2026, uses three HL7 v2 transactions between an Acquisition Manager and the scanner (^[7]) (^[8]). It assumes the slide barcode uniquely identifies the physical glass slide (^[9]). As of October 2026 DPIA is not final text, so procurement should ask for conformance statements and test evidence rather than assume the profile is universally implemented.

On scale, NEMA's worked example is an 80,000 x 60,000 pixel image of about 15 GB uncompressed (^[10]), and published institutional figures run from a projected 4.3 petabytes per year for a multisite network (^[11]) to 9 PB allocated at one cancer center (^[12]). This report supplies a capacity worksheet that uses slides per day, source size, conversion multiplier and retention copies, plus a concurrent-tile model, and it insists on local measurement rather than borrowed benchmarks. It also provides an identifier lineage table, a platform support matrix, a failure and retry list, and an eight-step pilot checklist. Annotations at scale belong in Microscopy Bulk Simple Annotations rather than Structured Reports, according to a 2026 preprint from the Imaging Data Commons team (^[13]). Vendor conformance varies by scanner and release, so every claim here should be re-checked against the specific conformance statement in your RFP.

This report examines how to connect scanners, laboratory information systems, picture archiving and communication systems (PACS), vendor neutral archives (VNA), viewers and machine-learning pipelines around DICOM whole slide images. It is written for digital pathology program owners, pathology IT architects, imaging core laboratories, medical-device product teams and AI-platform engineers. It is not a scanner ranking, a PACS comparison or a de-identification guide. The guidance is vendor-neutral: identity, retrieval and reconciliation testing deserve more design time than file-format debates.

History matters only as lineage. DICOM Working Group 26 was established in 2005 to extend the standard to pathology (^[14]). Supplement 145 introduced the whole slide IOD (information object definition), and a later peer-reviewed account notes that adoption lagged despite its publication in 2010 (^[15]). Supplement 145 is now folded into the maintained standard, so implementers should read the current edition of PS3.3, PS3.5 and PS3.18 rather than the historical supplement. The NEMA implementation page was last updated on January 27, 2026, and the standard text cited below is current as of October 2026.

The rationale for DICOM is infrastructure reuse. NEMA states that PACS capabilities for storing, archiving, retrieving, searching and managing images can be leveraged (^[16]). A multi-vendor implementation study concluded that DICOM lets healthcare enterprises leverage a wealth of existing medical imaging infrastructure (^[17]). A companion review argued that pathology laboratories going fully digital need to include WSI in an enterprise-level VNA, and that digital pathology storage needs dwarf those of radiology (^[18]) (^[19]).

Interoperability is also being tested in public. A 2025 Journal of Pathology Informatics report describes a Connectathon with over 30 digital pathology vendors and healthcare providers from around the world (^[20]). Existing explainers mostly answer PACS, viewer or vendor questions, so this report concentrates on the integration path.

The phrase "key changes" here means the structural shifts a team adopts when moving from proprietary slide files to DICOM: a tiled object model, identity inside the object, web retrieval, separate annotation objects and public conformance testing.

Change 1: A tiled multi-frame object replaces vendor tile stores

The current PS3.3 defines the VL Whole Slide Microscopy Image IOD as a multi-frame visible light image divided into a set of tiles (^[21]). Each frame encodes a single tile within a three-dimensional imaged volume, and the storage SOP class is named VL Whole Slide Microscopy Image Storage. NEMA describes the organization as a pyramid of image data. The basic mechanism stores the tiles of a single pyramid level as individual frames in a multi-frame object (^[1]), and each level is stored separately in the series (^[22]). A series may also hold ancillary images such as a slide label or macro image.

Two attributes decide how a reader finds a tile. The total pixel matrix describes the size of the entire imaged volume as one extent across all frames. The dimension organization is either TILED_FULL, where tile positions are implicitly defined (^[23]), or TILED_SPARSE, where positions are explicitly defined by per-frame functional group entries (^[24]). TILED_FULL is simpler for servers to index and cache; TILED_SPARSE accommodates scanners that skip blank tiles. A conformance test suite should include both. A layer's tiles may also span several instances of a concatenation or of a series, so a reader must not assume one file per level.

Frame arithmetic (illustrative calculation). For the NEMA example of 80,000 x 60,000 pixels, a 256 x 256 tile grid gives 313 x 235, or 73,555 base-level frames. A 512 x 512 grid gives 157 x 118, or 18,526 frames. NEMA gives typical tile sizes from 240 x 240 pixels (172 KB uncompressed) to 4,096 x 4,096 pixels (50 MB uncompressed) (^[25]). Frame count drives request count, so tile size is an architecture decision.

Change 2: Compression and transfer syntax become an interoperability variable

NEMA names JPEG and JPEG 2000 as the most frequently used lossy techniques. Its worked example shows JPEG 2000 reducing the roughly 15 GB image to about 300 MB, an approximately 50:1 ratio (^[26]). A 2022 review reports commonly used ratios of 10:1 to 20:1 for JPEG and 30:1 to 50:1 for JPEG 2000 (^[27]). One observer study on breast biopsy regions found performance nearly constant up to a ratio of 32:1 and a significant decrease at 64:1 and 128:1 (^[28]). Those are ranges from specific studies, not validated settings for a given scanner or diagnostic use.

PS3.5 explicitly allows RGB with lossy compression for whole slide images, to allow conversion from proprietary formats without loss due to color space transformation (^[29]). The change proposal behind this notes that compressed RGB components rather than YBR really are used by some WSI vendors. The consequence: a converter that passes compressed tiles through can preserve source pixels, but only if the server and viewer accept the resulting photometric interpretation and transfer syntax pair. In a multi-vendor study, baseline JPEG produced the smallest data size (^[30]). Platform support differs, and the Table 3 matrix below shows how the major services treat transfer syntaxes.

Change 3: DICOMweb is the retrieval contract

PS3.18 defines DICOMweb as the REST web services of the standard. Bulk data resources retrieve large data elements such as Pixel Data from instances, and pixel data is a subset of bulk data. The standard lets a service constrain the transfer syntax parameter on media types, which is why two compliant servers can return different bytes for the same frame request. Rendered images returned as image/jpeg are baseline lossy 8-bit (^[31]), so a rendered tile is a display derivative, not diagnostic source data.

Annotations and AI results are likewise conveyed in objects separate from the image, as NEMA states (^[32]); they are treated in the AI section below. As of October 2026 the IHE DPIA profile that governs the LIS-to-scanner link is still a trial-implementation document, discussed under the identity chain.

The first architectural decision is whether to normalize scanner output into DICOM at the source, convert it downstream, or coexist with proprietary formats. Table 1 below separates the three paths by what each one demands from the scanner, the integration layer and the archive. The table does not rank scanners; vendor statements are cited only to show that each path exists in documented form.

Path	How it works	Documented examples and limits	Main test burden
Native DICOM	The scanner or its bundled software writes VL Whole Slide Microscopy Image instances and sends them with DICOM or DICOMweb.	Leica's Aperio GT 450 DX brochure lists a native DICOM and SVS saving option ([3]), and a press release says the scanner produces DICOM WSI natively ([33]). Philips announced configurable native DICOM JPEG and JPEG XL output on its SGi scanner, which it describes as a world first (vendor claim, September 2025) ([34]). 3DHISTECH lists optional DICOM output for PACS interoperability ([35]).	Confirm which transfer syntaxes, tile sizes and Specimen module fields the scanner writes, per release and per country configuration.
Conversion or dual-personality	A converter reads a proprietary file and writes DICOM, or writes a file that is both a TIFF and a DICOM Part 10 file.	wsidicomizer opens proprietary formats and optionally converts them to DICOM ([36]); lossless conversion is offered for files supported by opentile ([37]), and z-stacks or multiple focal paths are documented as not supported ([38]). Philips documents a DICOM export that converts iSyntax to lossless JPEG 2000 ([4]). Bio-Formats can write dual-personality DICOM/TIFF files ([39]).	Pixel fidelity, metadata completeness, pyramid construction and the cost of keeping both the original and the DICOM copy.
Proprietary with viewer lock-in	The archive and viewer consume the vendor format. DICOM is produced only on export, if at all.	A 2019 paper notes that manufacturers, developers and users continue to depend on proprietary file formats ([6]). One enterprise imaging vendor states that not all scanner vendors produce images in a standard file format and that it supports several proprietary formats ([40]).	Exit cost, multi-vendor viewing, AI access to pixels and long-term retention readability.

The interpretive point is that "native" is a property of a scanner model, software release and licensed module, not of a brand. Philips states that it intends to support both DICOM and iSyntax formats for its IntelliSite Pathology Solution (^[41]). Evidence in the table is vendor-authored, so it indicates availability, not behavior in your environment; only a conformance statement plus your own acceptance tests are dependable.

Conversion fidelity: what is documented and what is not

Lossless pass-through of compressed tiles needs a library that reads tiles from the source container without recompression; opentile describes exactly that for WSI TIFF files (^[42]). The dual-personality proposal permits transcoding without further loss than present in the original source (^[43]). By contrast, wsidicom documents that levels must have a close to factor-2 scale and the same tile size (^[44]), and Bio-Formats supports uncompressed, baseline JPEG, JPEG 2000 and RLE lossless transfer syntaxes for DICOM (^[45]), narrower than what some scanners emit. OpenSlide lists DICOM as a supported multi-file format (^[46]) but is a reader.

No public benchmark of conversion fidelity across scanner families is known. A 2018 multi-vendor study showed that whole slide image data can be encoded with patient and specimen metadata as DICOM objects (^[47]), which establishes feasibility, not a fidelity guarantee. Define local acceptance criteria: byte-identical compressed tiles where lossless pass-through is claimed, a pixel-difference tolerance where re-encoding occurs, and a metadata completeness check against the LIS record.

The decision rule that follows from the table: choose native DICOM where a scanner model documents it and your archive accepts its transfer syntax; choose conversion for mixed or legacy fleets, budgeting a converter service and a second data copy during transition; accept coexistence only where a diagnostic viewer is bound to a proprietary format, and even then require DICOM export so exit remains possible.

Whole slide imaging scanner to LIS integration: specimen-container-slide identifiers

The workflow standards sit in the IHE Pathology and Laboratory Medicine (PaLM) domain. The identity chain has four hops: LIS case and specimen, container and slide label, scanner-read barcode, and the DICOM Specimen module. NEMA states that workflow outside the image object uses HL7 V2 transactions standardized in the IHE DPIA profile (^[48]), with patient, specimen and slide metadata retrievable using the identifier from the scanned barcode on the slide label (^[49]).

DPIA defines an Imaging Work Order Step (IWOS) as a service request that defines the detail for image acquisition (^[50]). The work order uses an HL7 v2 OML^O33 message that contains zero or more IWOSs for one or more specimens (^[51]). DPIA states that the barcode uniquely identifies the physical asset and can be used to link case data to slide data across all actors (^[9]). Its Study Instance UID maps one to one with the case accession number (^[52]), and a pathology accession equates to one study (^[53]). That mapping has a design consequence: in an illustrative layout, a case with 40 slides becomes one study with about 40 series, which affects QIDO paging and viewer worklists.

DICOM also supports a worklist route. PS3.17 describes the Modality Worklist use for specimens, in which the contents of the Specimen Module may be conveyed in the Scheduled Specimen Sequence of the worklist query (^[54]). In practice, DPIA acknowledges that the scope of the acquisition modality generally includes the scanner and its vendor middleware (^[55]), so the LIS-to-scanner link often hides inside one vendor's software.

Table 2 below traces each identifier from source to image object. Mapping rows come from the DICOM Specimen module text and the DPIA appendix; the reconciliation column is analytical guidance and should be validated locally.

Identifier	Created by	Where it lands in DICOM	Reconciliation check
Accession number (case)	LIS	Study-level accession; maps to Study Instance UID one to one in DPIA	One study per accession; no study split across archives.
Specimen identifier	LIS	Specimen Identifier, a departmental information system identifier; DPIA maps it from HL7 SPM-2 ([56])	Every series resolves to a specimen in the LIS; no orphan specimens.
Container (slide) identifier	LIS, printed as slide barcode	Container Identifier, the container that contains the specimens being imaged ([2]); DPIA maps it from SAC-3	Barcode read equals LIS record; duplicates flagged before archive commit.
Issuer of identifiers	LIS site policy	Issuer of the Container Identifier Sequence, carried in the same Specimen module as the container identifier	Multi-site: issuer namespaces are unique, or identifiers collide after merger.
Specimen UID	LIS or Acquisition Manager	Specimen UID, carried inside the Specimen Description Sequence ([57])	Stable across rescans of the same slide.
Slide label image	Scanner	Ancillary image in the series	Label OCR or barcode matches metadata; label image retention follows privacy policy.

The table makes visible that the same logical slide appears under at least four names. Where a pathology system also exposes HL7 FHIR, a FHIR ImagingStudy provides information on a DICOM imaging study (^[58]), and a FHIR Specimen carries a separate accession identifier assigned by the lab when accessioning specimens (^[59]); the two should reference one another by identifier, never by free-text label.

Conversion pipeline design

Where conversion is needed, treat it as a service with its own queue, idempotency key and audit trail. Microsoft's documentation recommends uploading each converted WSI as a DICOM series with multiple instances (^[60]). A defensible design has three parts:

• Landing zone and converter workers: the scanner writes proprietary output to a quarantined share; stateless workers run a documented tool (for example wsidicomizer or a vendor export) with pinned versions recorded in each output.
• Metadata join: the worker fetches case, specimen and container data from the LIS by slide barcode, and refuses to write if a required field is empty.
• Verification and commit: compare frame counts, total pixel matrix dimensions and a sampled tile hash against the source before STOW, then write a manifest of every SOP Instance UID; keep the source file until the manifest reconciles.

Open-source tools are good test baselines, but production use needs a validation plan appropriate to your regulatory context.

DICOMweb whole slide images: STOW, QIDO and WADO data flow

The data flow is: scanner or converter sends instances with STOW-RS (store); viewers find studies and series with QIDO-RS (query); viewers and AI workers fetch metadata and frames with WADO-RS (retrieve). A 2018 enterprise-WSI briefing lists these archive requirements: take care at 2 GB and 4 GB boundaries such as frame byte offsets (^[61]), and support QIDO-RS and WADO-RS for viewer query, metadata and frame-level retrieval (^[62]). Those are still good test cases.

Service limits differ and should be written into the RFP. Azure's DICOM service limits requests to 4 GB (^[63]) and accepts only explicit-VR transfer syntaxes (^[64]); AWS HealthImaging announced import of instances up to 4 GB (^[65]); Google lists a limit of 4 GB per tag on ingested files (^[66]). A 15 GB uncompressed instance would exceed these, so compressed storage or concatenated instances must be settled before purchase. For frame retrieval, Microsoft recommends parallel single-part GET requests (^[67]), while Google notes that retrieving an entire instance is generally faster per frame than batch retrieval (^[68]). These apply to different access patterns; only local measurement shows which fits your viewers and AI jobs.

Failure and retry matrix

Define each failure mode, the expected system behavior, and the reconciliation action before go-live:

• Barcode unreadable or LIS order not found: hold the slide in the landing zone, retry the IWOS query on a schedule, and escalate after a defined number of attempts; never create DICOM without a resolvable specimen.
• STOW timeout or partial series: retry with the same SOP Instance UID so the second attempt is idempotent, then compare QIDO counts with the manifest and re-send only missing instances.
• Unsupported transfer syntax: the archive rejects or transcodes; Azure documents transcoding to the requested transfer syntax on retrieval (^[69]), which helps viewers but hides what is stored, so record the stored syntax in the manifest.
• Rescan: produce a new series under the same study with an auditable supersession flag, not an overwrite.

Digital pathology PACS integration: VNA, object store and cache architecture

A PACS or VNA is acceptable for WSI only if it handles multi-GB instances, frame-level access and large studies. The 2018 VNA review argues that fully digital laboratories need WSI in an enterprise-level archive, and the 2018 briefing lists frame-level retrieval and query support as archive requirements. Memorial Sloan Kettering's published design keeps about six months of scanned slides on a fast tier for viewer access and moves older slides to cheaper disk (^[70]). Google documents a digital pathology proxy that performs just-in-time frame caching to serve frames from an in-memory Redis cache (^[71]).

For storage planning, three rules follow. First, keep a hot tier sized to recent cases plus conference and tumor-board reuse, not to the whole archive. Second, put a frame cache in front of the archive, sized from measured viewport patterns. Third, define lifecycle policy per copy so that DICOM, the original proprietary file and any derived results can be retired independently.

Viewer and annotation interoperability

Viewers differ in what they consume. Slim runs fully client side and communicates with servers via standard DICOMweb (^[72]); its authors report interoperability with five commercially available enterprise-grade VNAs (^[73]). OHIF advertises out-of-the-box support for image archives which support DICOMweb (^[74]), and QuPath reads DICOM WSI through Bio-Formats (^[75]), so an analyst tool may read files rather than use DICOMweb. Viewer selection should therefore be a test matrix of image, annotation, segmentation and measurement objects, not a feature checklist.

AI inference, bulk annotations, segmentation and structured results

Digital pathology AI integration architecture has four parts: tile access, inference orchestration, result encoding and result display. For tile access, The dicomslide library, for example, dynamically retrieves only the image frames (tiles) needed for a requested region (^[76]). A pipeline that copies whole slides to local disk first gives up that benefit and creates an unmanaged extra copy. An AWS reference architecture places machine-learning models on SageMaker AI endpoints that perform inference on whole slide images (^[77]); it is vendor material, not an independent evaluation.

For orchestration, the IHE AI Workflow for Imaging (AIW-I) profile specifies workflow-management transactions based on the DICOM UPS-RS worklist service (^[78]), and tasks may be managed with pull, triggered-pull or push workflows (^[79]). The companion AI Results profile addresses capture, distribution and display of medical imaging analysis results (^[80]). Both are radiology profiles, and the AI Results profile text contains no pathology content, so using them for slides is an adaptation that must be tested. Platform support for the worklist half is uneven: Azure lists a worklist service with UPS push and pull (^[81]), while Google states it does not support the Worklist Service (^[82]).

For results, the choice among objects is driven by cardinality and geometry:

• Microscopy Bulk Simple Annotations (MBSA): a collection of points, closed polygons, open polylines and simple geometric shapes, organized into annotation groups that share common characteristics. Supplement 222 says the annotations share a 3D Frame of Reference with a whole slide image instance and introduce no new image encoding mechanism (^[83]).
• Segmentation: binary, fractional or label map segmentations, suited to masks that behave like images.
• Structured Reports (SR): the Python library highdicom supports Structured Report documents containing numerical results, qualitative evaluations and vector graphic annotations (^[84]). SR suits a manageable number of regions with rich measurements.
• Presentation states: the Advanced Blending Presentation State blends two or more sets of images referenced from within the IOD, which suits channel combinations and display recipes, not diagnostic findings.

The 2026 Imaging Data Commons preprint gives practical guidance: MBSA should be preferred when there are many regions, with or without measurements (^[13]), because automatically generated cell boundaries in a pathology image can easily number in the tens of thousands (^[85]). It reports that MBSAs can contain hundreds of thousands of regions (^[86]). It also identifies a gap: DICOMweb does not yet define an API for spatial querying of MBSAs or SRs (^[87]). The architectural implication is that a viewer must download an entire annotation object, so result objects should be partitioned (for example per tissue region or per model output group) if viewer responsiveness matters. Supplement 255, a draft supplement at the time of review (check the DICOM supplements page for final-text status), proposes enhanced annotations for quantized heatmap regions, holes and voids, and nested mutually exclusive concepts (^[88]); do not build to it before it is final.

Whichever object you pick, store the producing algorithm identity, model version and input series UIDs in a way the archive can query, and verify that this information round-trips through your archive and viewer. If the information is held in a private convention, document it in your own conformance statement so that a later migration does not lose provenance.

Performance, integrity, retry and reconciliation testing

Performance tests should use your slides, your network and your viewers. Published numbers are specific to their setups: a 2018 multi-vendor study reported that baseline JPEG gave the smallest data size, and a viewer-server paper reports interoperability results rather than a universal latency. A vendor-published throughput figure for one cloud service is not a basis for sizing a different deployment, so this report does not reuse any. A minimum test plan:

• Tile latency distribution: record p50, p95 and p99 from the viewer for pan and zoom at 20x and 40x on a representative slide set, cold and warm cache.
• Concurrency ramp: raise concurrent readers until p95 exceeds the target; record the knee.
• Integrity: hash every frame at the source and after retrieval for a sample of slides; compare SOP Instance UID lists to the manifest.
• Transfer syntax matrix: store and retrieve each syntax your scanners emit through each service, and check whether the service transcodes or preserves bytes (^[89]).
• Failure injection: kill the converter mid-STOW and drop the LIS interface for an hour; confirm reconciliation recovers without manual DICOM edits.
• Rendered versus native frames: rendered image/jpeg output, which is baseline lossy 8-bit, must never serve as AI input or archive copy.

Table 3 below is a platform support matrix drawn from vendor documentation. It lists what each documents for DICOMweb and large-image handling and is not a ranking; every cell should be re-verified against the current release before purchase.

Platform (documentation)	DICOMweb services documented	Large-image and transfer-syntax notes	Pathology-relevant notes
Azure DICOM service	STOW-RS, WADO-RS, QIDO-RS and a worklist service with UPS push and pull	4 GB request limit; explicit-VR transfer syntaxes only	States a format conversion is required for WSI in other formats ([5]); designed for multi-GB instances ([90]).
Google Cloud Healthcare API	Studies service; no URI service, worklist service or capabilities transactions	4 GB per tag limit on ingested files	Pyramid levels stored as frames ([91]); import via DICOMweb, DIMSE or Cloud Storage ([92]).
AWS HealthImaging	DICOMweb representations not available through AWS CLI and SDKs ([93])	Any SOP class UID importable ([94]); HTJ2K default storage, JPEG 2000 Lossless configurable ([95])	Faster import of large instances such as whole slide imaging announced May 2025 ([96]).
Orthanc (open source)	DICOMweb plugin; the full standard is not implemented yet ([97])	WSI plugin re-encodes some tiles to PNG for display ([98])	Includes a converter and web viewer for whole-slide images ([99]).

The matrix shows why a product name is not a conformance claim: two services can both support DICOMweb while differing on worklists, size limits and transcoding. Ask each supplier for a current conformance statement and run the same acceptance suite against each.

Migration, pilot plan and RFP questions

A pilot sized for evidence, not demonstration, has eight steps:

1. Inventory and success metrics: list scanners, firmware, formats, LIS interfaces, viewers and AI tools; set targets for identity match rate, tile latency, integrity pass rate and reconciliation time.
2. Select a slide set with special cases: multi-section slides, immunohistochemistry, large blocks and rescans.
3. Build the identity chain first: LIS order to barcode to Specimen module, tested before any pixels move.
4. Run native and converted paths side by side for the same slides, comparing metadata and tiles.
5. Load test the archive and cache using the capacity worksheet below.
6. Add AI results as DICOM objects and confirm the viewer displays them without custom code.
7. Validate for diagnostic use under your governing guidance. The College of American Pathologists validation guideline update recommends at least 60 cases for one application or use case (^[100]) and a washout period of at least 2 weeks between viewing digital and glass slides (^[101]), as quoted in a secondary paper. Consult the guideline and your regulator for binding requirements.
8. Plan exit: prove that you can export every slide and result as DICOM without vendor tools.

For the RFP, ask each supplier these questions:

• Which SOP classes, transfer syntaxes and tile sizes are written and read, per release, and is the LIS-to-scanner interface (DPIA role) documented?
• Which DICOMweb transactions are supported, with what size, paging and timeout limits, and can stored bytes be retrieved unmodified?
• How are annotations, segmentations and AI results stored and queried, and what export path exists for the full archive in standard DICOM?
• What evidence from public connectathons or independent tests exists for the exact version offered?

The quantitative core combines published reference points with a worksheet that readers fill with local measurements.

Published reference points

NEMA's example of a 20 mm by 15 mm sample at 0.25 micrometers per pixel gives 80,000 x 60,000 pixels, about 4.8 gigapixels (^[10]), or about 15 GB at 24-bit color (^[102]). Its extreme example, 125 gigapixels per plane across ten planes, reaches 3.75 TB (^[103]). Generating pyramid levels a factor of 2 apart adds about 32% to the data set (^[104]). Institutional figures vary by scanner, magnification, compression and policy: a 2022 review states large pathology centers may produce over 1 million digital slides and around 1 petabyte per year (^[105]); a 2018 multisite estimate projected about 4.3 petabytes per year (^[11]); and Memorial Sloan Kettering reported allocating 9 PB for slide storage (^[12]). They differ in year, compression and scope, and none is a forecast for your laboratory.

Capacity worksheet

The storage formula is: annual stored volume = slides per day x operating days x average source size x conversion multiplier x retention copies. The concurrency formula uses Little's law: required throughput (requests per second) = concurrent tile requests in flight divided by target response time in seconds.

The worksheet inputs, each to be replaced with a local measurement, are:

• Slides per day and operating days: from LIS accession logs.
• Average source size: the mean file size on your scanners at your magnification and compression settings.
• Conversion multiplier: 1.0 for native DICOM only, 2.0 if the proprietary original is kept alongside a DICOM copy.
• Retention copies: primary, disaster recovery and any research replica.
• Concurrent tile requests and target response time: from viewer logs and a reader-experience target agreed with pathologists.

(Hypothetical Example) A laboratory scans 800 slides per day on 250 operating days. Local measurement of recent scans gives an average source size of 1.0 GB. The laboratory keeps the proprietary original and a DICOM copy during transition (conversion multiplier 2.0) and holds two retention copies (primary and disaster recovery). Annual volume is 800 x 250 x 1.0 GB = 200 TB of source data, times 2.0 for the dual representation = 400 TB, times 2 copies = 800 TB per year. After migration, with native DICOM only (multiplier 1.0), the same laboratory would store 400 TB per year. If instead the conversion regenerates pyramid levels a factor of 2 apart that the source did not store, the NEMA overhead of about 32% would raise the native-only figure to about 528 TB.

For viewing, suppose a 1920 x 1080 viewport over 256-pixel tiles needs about 40 tile requests per view refresh (8 columns x 5 rows). With 30 concurrent readers panning at once, 1,200 requests are in flight. With a target response time of 250 ms, the origin must sustain 1,200 / 0.25 = 4,800 requests per second at peak. A cache hit ratio of 70% would reduce origin load to 1,440 requests per second. Every input in this example is an assumption to be replaced by measurement, and the numbers illustrate the method, not a recommendation.

The first sensitivity worth running is the conversion multiplier: whether the proprietary original is retained for the full retention period or only until reconciliation completes can change volume by a factor of two.

What the evidence does and does not support

Strong evidence supports the structural claims (tiled frames, pyramid levels as separate instances, specimen identity in the Specimen module, DICOMweb retrieval), because they come from the standard itself. Moderate evidence supports compression ranges, which come from a review and an observer study with specific test conditions. Cross-vendor conversion fidelity, enterprise-scale DICOMweb tile performance and independent archive comparisons lack public benchmarks, which is a reason to budget for local testing, not to defer standards-based design.

Three shifts are likely to shape procurement over the next planning cycle. First, native DICOM output is becoming a documented option across more scanner families, with at least one vendor announcing native DICOM output in both JPEG and JPEG XL as of September 2025, and AWS announcing JPEG XL support for its imaging service in early 2026, naming whole slide imaging systems as an example consumer (^[106]). Codec choice is therefore a joint scanner and archive decision.

Second, the identity chain is moving from vendor middleware toward a published profile. DPIA is at trial-implementation status (^[7]), and the draft IHE Digital Pathology Ordering and Workflow work says adherence to DPIA plays an important part in a successful implementation (^[107]). Programs that capture identifiers cleanly now will find later profile adoption cheaper.

Third, AI results are becoming first-class DICOM objects: the Slim viewer is described as the slide microscopy viewer of the NCI Imaging Data Commons (^[108]), but the absence of a spatial query API for bulk annotations means viewers will keep downloading whole annotation objects for some time.

For organizations deciding whether to normalize to DICOM, the implications are practical. A mixed fleet will keep a conversion tier for years, so budget it as production infrastructure. Choose archives on documented frame-level access, size limits and transfer-syntax behavior, and keep an exit path: exporting every slide, annotation and AI result in standard DICOM is the strongest hedge against format and vendor change. Independent expertise can help structure the RFP, acceptance suite and governance; it does not replace vendor conformance statements, a clinical validation plan or regulator guidance, and quality and compliance teams should be involved before any diagnostic deployment.

What is DICOM whole slide imaging?

DICOM whole slide imaging is the use of the DICOM standard to store and exchange digitized microscope slides as tiled, multi-frame images with a multi-resolution pyramid. The IOD specifies a multi-frame visible light image divided into a set of tiles, and each pyramid level is stored separately in a series.

Is DICOM Supplement 145 still the reference?

Supplement 145 is the historical origin of the whole slide IOD, published in 2010. For normative details use the current standard, for example PS3.3 section A.32.8 and PS3.18 for DICOMweb.

How does a scanner connect to the LIS?

Usually through HL7 v2 transactions, standardized in the IHE DPIA profile, with the slide barcode as the link to case data. Many deployments hide this link inside vendor middleware, so request interface documentation.

DICOM WSI versus proprietary scan formats: which is better?

Neither choice is universally better. DICOM enables reuse of enterprise imaging infrastructure, while proprietary formats persist in scanners and software. The decision depends on exit cost, multi-vendor viewing and AI access, covered in Table 1.

DICOM whole slide imaging integration succeeds or fails on the chain from LIS identifier to scanner barcode to Specimen module, and on whether the archive can serve frames at the speed readers and models need. The standard supplies tiled multi-frame objects, specimen metadata, DICOMweb retrieval and separate annotation objects; the vendor ecosystem supplies native, converted and proprietary paths, each documented to a different degree and changing by release.

The recommended stance is to treat DICOM as the system of record, conversion as a tested service, and conformance statements as the start of local acceptance testing. Size storage and delivery with the worksheet, using your own slide sizes and tile latency measurements, and insist on an export path in standard DICOM. Because DPIA is still at trial-implementation status as of October 2026 and vendor support differs by scanner and release, revalidate every decision here against the specific products and versions in your procurement.