Digital pathology adoption in academic medical centers is not primarily a scientific problem. The science of whole-slide imaging, AI-assisted analysis, and computational biomarker scoring is mature enough. The friction is infrastructural: how does a NDPI file produced by a Hamamatsu NanoZoomer slide scanner flow into a clinical decision-making context, and what does it mean for a lab information system that was designed around numeric HL7 result messages to suddenly need to surface a 2 GB image as a relevant clinical document?
This piece is aimed at lab IT architects, pathology department informatics leads, and LIS administrators who are evaluating digital pathology integration and want to understand the landscape before committing to implementation decisions. The technical depth here is moderate — we are not writing a DICOM conformance statement, but we are assuming familiarity with HL7 messaging and LIS workflow concepts.
The Fragmented Landscape of WSI File Formats
The first friction point is the file format fragmentation at the scanner level. The four major whole-slide scanner vendors each have a proprietary container format as their primary output:
- .svs — Aperio (Leica Biosystems), based on LibTIFF with a pyramidal TIFF structure and metadata in a vendor-specific tag. Widely supported by analysis platforms.
- .ndpi — Hamamatsu NanoZoomer. A TIFF-like container with a proprietary multi-level tile structure. Somewhat less universally supported than SVS.
- .mrxs — 3DHISTECH Pannoramic series. A directory-based format (not a single file) where the index file points to multiple tile data files. Requires vendor SDK or OpenSlide for programmatic access.
- .scn — Leica SCN/ScanScope. Less common in newer deployments as Leica has shifted toward .svs for its GT series.
The nominal solution to this fragmentation is DICOM-WSI: a profile of the DICOM standard (supplement 145, now mature and incorporated into the DICOM standard proper) that defines how whole-slide images are stored as multi-frame DICOM objects with pyramidal resolution levels. DICOM-WSI support in scanners is improving — Aperio GT 450 supports DICOM output, Hamamatsu has DICOM export capabilities in recent firmware — but a significant installed base of older scanners outputs only proprietary formats. Any integration architecture must handle both pathways.
Where DICOM-WSI Helps and Where It Does Not
DICOM-WSI solves the transport and archival problem elegantly once you have it. A DICOM-WSI object can be stored in a standard PACS (Picture Archiving and Communication System), retrieved via standard DICOMweb APIs (WADO-RS, STOW-RS, QIDO-RS), and linked to patient demographics and order context through standard DICOM attributes. A pathology department already running a vendor-neutral archive (VNA) for radiology imaging can, in principle, extend that infrastructure to whole-slide images without a parallel proprietary pathology image management system.
The reality is more complicated. DICOM-WSI file sizes are large — a 40x full-slide scan of a core biopsy is typically 1–4 GB; a surgical resection at 40x can be 8–20 GB. Standard PACS architectures were not designed with these object sizes in mind, and DICOMweb WADO-RS retrieval of a 15 GB object as a single transaction is not the right operational model for image viewing. Effective DICOM-WSI viewers use tiled retrieval — requesting only the resolution level and tile region currently displayed — which works well with DICOMweb but requires viewer software explicitly designed for pyramidal tile access, not traditional DICOM retrieval patterns.
For AI analysis tools operating on DICOM-WSI, the access pattern is different again. A model doing whole-slide tissue inference needs to access all tiles at one or more resolution levels, not just the viewport tiles. This puts different throughput demands on the storage backend than interactive viewing does, and architectures designed for one use case may perform poorly for the other.
LIS Integration: The Accession-Driven Workflow
In the typical pathology department workflow, the LIS is the authoritative source of case identity. Cases arrive as accession numbers; the LIS tracks specimen type, processing blocks, stain requests, and result disposition. Any digital pathology tool that produces a clinically relevant output — including an IHC biomarker score — needs to route that output back to the correct LIS accession.
The standard integration mechanism for this is an HL7 v2.x result message, specifically the ORU^R01 message type. The scoring algorithm's output (e.g., HER2 IHC score, PD-L1 TPS) is encoded as an OBX (Observation Result) segment, with appropriate LOINC codes for the test, numeric or coded values for the result, and reference ranges where applicable. This routes directly into the LIS result workflow, where the pathologist can review the algorithmic score alongside other case data and incorporate it into the diagnostic report.
The challenge with HL7 v2 ORU integration for IHC scoring is that the result payload is richer than a simple numeric value. An IHC scoring report includes a discrete score, confidence information, the cell count data underlying the score, and ideally a spatial heatmap image summarizing where positive cells were detected. HL7 v2.x OBX segments handle discrete values and embedded images (via ED data type) but the rich-report use case increasingly motivates migration toward FHIR DiagnosticReport resources, which natively support structured data plus referenced document or image attachments.
HL7 FHIR: The Integration Direction of Travel
FHIR R4 (and the ongoing R5 development) provides a more expressive data model for pathology results than HL7 v2. A FHIR DiagnosticReport resource can reference Observation resources for each scored biomarker, link to the source ImagingStudy (the WSI), and attach a DocumentReference pointing to the PDF report. FHIR Observation resources support LOINC-coded test identifiers, quantitative values with units, and structured component observations for sub-values (e.g., both TPS and CPS as components of a single PD-L1 observation).
The practical constraint is that most production LIS systems still speak HL7 v2 natively. FHIR interfaces in LIS systems exist but are often limited to specific functional areas (order management, result retrieval for EHR consumption) rather than full inbound result ingestion. An AI scoring tool targeting integration with a clinical LIS today should support HL7 v2 ORU^R01 as the primary result delivery mechanism, with FHIR as an additional pathway for institutions running FHIR-capable LIS infrastructure or direct EHR integration.
We are not saying FHIR is premature for pathology integration — pilot deployments at academic health systems are demonstrating real value. What we are saying is that a vendor promising FHIR-only integration in 2025 is assuming an LIS modernity that many actual clinical sites do not yet have, and a pragmatic tool supports both.
Authentication, Audit Trails, and HIPAA Considerations
Any system transmitting PHI (Protected Health Information) — which all IHC scoring systems do, since they process case-linked tissue images — must satisfy HIPAA Security Rule requirements for access control, audit controls, integrity, and transmission security. For integration with a clinical LIS, this means TLS-encrypted HL7 connections (typically TLS 1.2 or 1.3 over MLLP), authenticated API endpoints (OAuth 2.0 with appropriate scopes for FHIR, certificate-based for HL7 v2 MLLP), and comprehensive audit logging of who accessed which case data at what time.
CLIA laboratory requirements add an additional layer. For a tool used to inform clinical reporting, the software must be treated as part of the laboratory's quality system. This means version-controlled software with documented change control, validation records demonstrating that software updates do not change analytical performance, and — critically — a clear functional demarcation between the algorithm's output and the pathologist's final diagnostic interpretation. The algorithm provides a measurement; the pathologist's sign-off provides the diagnosis. This distinction must be architecturally enforced in the integration, not just stated in documentation.
Practical Deployment Patterns
In practice, academic cancer centers evaluating digital pathology AI tools fall into one of three infrastructure configurations. The first is scanner-first: the department has invested in slide scanning infrastructure but lacks a dedicated pathology image management system, relying on a shared network drive or basic WSI viewer with no LIS connectivity. Integration here starts with API-based file upload and webhook-driven result delivery rather than DICOM or HL7 orchestration.
The second is PACS-connected: the department has a DICOM-capable pathology storage system, possibly a shared VNA with radiology, and expects DICOM-WSI input and DICOM SR (Structured Report) output. Integration requires full DICOMweb conformance on both ends and DICOM SR template support for pathology measurement results.
The third is LIS-integrated: the department wants algorithmic scores routed directly into the LIS result workflow, indistinguishable in the reviewer interface from any other laboratory result. This requires HL7 v2 ORU integration, LIS-specific field mapping for accession linkage, and coordination with the LIS vendor for custom result display configuration.
None of these is inherently better. The right answer depends on the department's existing infrastructure, IT governance constraints, and how tightly the IHC scoring output needs to be embedded in the clinical documentation workflow. Getting this assessment right before a deployment commitment is the single most important preparation step, and it requires infrastructure-level conversations that go beyond what any tool's marketing materials will tell you.