XyDromatics Pathology Engine Specialized engine · WSI conversion · Windows-only

XyDromatics Pathology Engine — native scanner files in, DICOM WSI out.

The whole-slide imaging sidecar. Watches an intake folder for native scanner files (Aperio SVS, Hamamatsu NDPI, 3DHistech MRXS, Roche BIF, Leica SCN, Zeiss ZVI, pyramidal TIFF), converts to DICOM Supplement 145 WSI with full multi-resolution pyramid, forwards via STOW-RS to your VNA.

The only Windows-only product in the family — by deliberate design (OpenSlideNET native dependency). The rest of the router-pattern hosts ship cross-platform. HIPAA mode is license-gated for clinical use; same family-platform features (keyed-hash pseudonymization, honest-broker capability, AI-vendor PHI-shielded round-trip) as the rest of the family.

The OS exception

Windows-only by deliberate design.

Pathology Engine is the only Windows-only product in the XyDromatics family. The rest of the router-pattern hosts — Router, VNA family, SR Engine, Migration Engine, Encounter Engine — ship cross-platform. Pathology Engine doesn’t, for a specific technical reason worth understanding before you plan the deployment.

Whole-slide-imaging vendor formats (Aperio SVS, Hamamatsu NDPI, 3DHistech MRXS, Roche BIF, etc.) are read by the OpenSlide library, which depends on a stack of native C libraries (libtiff, libpng, libxml2, glib, vendor-specific decoders). The .NET binding (OpenSlideNET) wraps these via P/Invoke. The whole stack compiles cleanly on Windows. Cross- compiling for Linux is harder than it sounds because of those native dependency chains.

Rather than ship a partially-functional Linux build, IPE is Windows-only by design. We’d rather have one OS work reliably than two OSes work flakily. The rest of the family stays cross-platform; IPE is the deliberate exception.

Deployment implication

If your standard server platform is Linux, IPE will require a Windows host (or VM) somewhere in your imaging stack. Plan for it during discovery — usually a single Windows host per IPE deployment is sufficient, with the rest of your XyDromatics products running on whichever platform your team prefers.

Capabilities

Native scanner files to DICOM WSI, in one sidecar.

The capabilities below cover the conversion pipeline, DICOM Sup 145 output, watch-folder ingest, the license-gated HIPAA mode, and the family-platform features (keyed-hash, broker, audit) that you get across every router-pattern host.

Native WSI format conversion

Pathology scanners produce vendor-native WSI formats — IPE converts them all to DICOM Supplement 145 WSI for vendor-neutral archiving.

  • Aperio SVS (Leica Biosystems / GT450, AT2, ScanScope)
  • Hamamatsu NDPI (NanoZoomer S60, S210, S360, RS, XR)
  • 3DHistech MRXS (Pannoramic series, now Sysmex)
  • Roche / Ventana BIF (DP200, DP600, DP1000)
  • Leica SCN (SCN400)
  • Zeiss ZVI / CZI (Axio Scan)
  • Pyramidal TIFF (generic, BigTIFF)
  • DICOM Sup 145 passthrough (already-DICOM scanners)

DICOM Supplement 145 output

The DICOM standard for whole-slide imaging — multi-resolution pyramid, tile-based access, embedded label and overview images.

  • SOP Class 1.2.840.10008.5.1.4.1.1.77.1.6 (VL Whole Slide Microscopy Image Storage)
  • Multi-resolution pyramid generation matching source scanner levels
  • Tile-based access for browser-friendly retrieval
  • Label image + overview image embedded per WSI
  • Optical-path metadata preserved (objective magnification, immersion media, illumination)
  • Per-slide DICOM-tag normalization (institutional accession-number formats, study description)

Watch-folder ingest

Pathology workflow is historically file-based. IPE meets the workflow where it lives — drop native files into an intake folder, the engine handles the rest.

  • Configurable watch directory(s) per scanner / per project
  • File-stability detection (waits for upload completion before processing)
  • Per-scanner ingest profiles (different vendor scanners behave differently)
  • Failed-conversion quarantine queue for clinical adjudication
  • Concurrent multi-file processing with configurable parallelism
  • Audit trail captures every ingested file end-to-end

STOW-RS forwarding

After conversion, IPE forwards the DICOM WSI to the target archive via standard STOW-RS — works with any DICOM-conformant VNA, not just XyDromatics.

  • STOW-RS forwarding to XyDromatics VNA family (Repository / Clinical / Research / Clinical Research)
  • STOW-RS forwarding to any DICOM-conformant third-party VNA
  • Per-target throughput throttling
  • Failed-forward retry with dead-letter queue
  • Confirmation ACK back to source for upstream acknowledgment

HIPAA mode (license-gated)

HIPAA mode is a license feature — not a free configuration toggle. Deliberate design control under the non-device posture (§520(o)(1)(D)): clinical use requires explicit license entitlement.

  • License-gated HIPAA mode — `hipaa_mode` license feature must be present
  • Without HIPAA license: research / development mode only (RUO-flavored)
  • PHI-free by default — engine starts in non-clinical mode unless license proves entitlement
  • Config force-reset to HIPAA-off at startup if license is missing or invalid
  • Strict feature-license check in code, not just label — license-feature-enforcement-pattern (DOC reference)
  • Audit captures HIPAA-mode state with every action for inspection-ready evidence

Family-platform features

Same family-wide platform features as the rest of the router-pattern hosts.

  • Keyed-hash pseudonymization with shared site encryption key (anon-IDs consistent across the customer's product portfolio)
  • Built-in honest-broker capability for studies anonymized by IPE
  • AI-vendor PHI-shielded round-trip workflow (digital pathology AI is a fast-growing space)
  • Web administration UI with shared sidebar shell
  • Role-based access control with full permission catalog
  • Hash-chain audit log + 21 CFR Part 11-aligned audit trail

Architecture

Scanner → watch folder → IPE → DICOM target.

Pathology workflow has historically been file-based. IPE meets that workflow where it lives — scanner drops native file into intake folder; engine handles conversion + forward.

XyDromatics Pathology Engine architecture Pathology scanners produce native WSI files (Aperio SVS, Hamamatsu NDPI, 3DHistech MRXS, Roche BIF, etc.) into a watched intake folder. IPE detects file completion, converts to DICOM Supplement 145 WSI with multi-resolution pyramid generation, and forwards via STOW-RS to the target VNA or AI vendor. HIPAA mode is license-gated for clinical use. PATHOLOGY SCANNERS IPE (Windows-only) DICOM TARGETS Pathology scanners Aperio SVS Hamamatsu NDPI 3DHistech MRXS Roche BIF Leica SCN · Zeiss CZI Pyramidal TIFF native files files IPE Windows-only · Non-device software 📁 Watch folder ingest (file-stability detection) OpenSlide-based conversion → DICOM Sup 145 Multi-resolution pyramid + tile-based output HIPAA mode (license-gated) Keyed-hash anon · Honest-broker capability Same site encryption key as Router / VNA / SR Engine / Migration Engine STOW-RS XyDromatics VNA family Repository · Clinical · Research Pathology PACS DICOM Sup 145-aware Third-party VNA any DICOM-conformant Digital pathology AI PHI-shielded round-trip Windows-only by design OpenSlideNET native dependencies. Plan for a Windows host even if the rest of your stack is Linux.

Use cases

Five WSI-specific deployment patterns.

Pattern 1

Production WSI-to-DICOM conversion pipeline

The primary pattern: pathology scanners produce native files; IPE converts to DICOM Sup 145 WSI; converted slides land in the VNA for vendor-neutral archive + clinical retrieval. Replaces the patchwork of vendor-specific tooling that pathology departments often accumulate.

Flow

  1. 1 Pathology scanner produces native WSI file (SVS / NDPI / MRXS / etc.) into the watch folder
  2. 2 IPE detects file completion, identifies the format
  3. 3 Conversion to DICOM Supplement 145 WSI with multi-resolution pyramid generation
  4. 4 Per-slide tag normalization (accession-number format, study description, etc.)
  5. 5 STOW-RS forward to target VNA
  6. 6 Audit log retains the full ingest-convert-forward chain
Pattern 2

WSI archive consolidation onto DICOM

A pathology department with years of accumulated scanner-native WSI files (in vendor-proprietary formats, often siloed by scanner) wants to consolidate onto a vendor-neutral DICOM archive. IPE batch-processes the historical archive into DICOM Sup 145.

Flow

  1. 1 Existing scanner-native files staged in batch ingest folders
  2. 2 IPE processes in scheduled windows (overnight / weekend) at controlled parallelism
  3. 3 Per-scanner profile handles vendor-specific quirks
  4. 4 Converted DICOM WSI forwarded to target archive
  5. 5 Per-slide audit trail proves what was converted and when
  6. 6 Original native files retained per institutional policy until conversion is verified
Pattern 3

AI-vendor digital pathology integration (PHI-shielded)

Digital-pathology AI is a fast-growing space (Paige, PathAI, Ibex, Mindpeak, Indica Halo, others). IPE supports the family-wide PHI-shielded round-trip — de-identify on the way out, AI vendor analyzes, findings come back, IPE re-identifies via keyed-hash pseudonymization.

Flow

  1. 1 Slide qualifies for AI analysis per institutional policy
  2. 2 IPE de-identifies via keyed-hash pseudonymization (anon-ID derived from PHI + system encryption key)
  3. 3 De-identified DICOM WSI sent to AI vendor (vendor sees only anon-ID)
  4. 4 AI vendor analyzes (tumor detection, biomarker scoring, etc.), returns findings tagged with anon-ID
  5. 5 IPE re-identifies via the retained mapping
  6. 6 Findings forwarded to pathology PACS / EMR / reporting platform linked to the correct case
Pattern 4

Research-cohort WSI preparation

Research project requires de-identified WSI cohort for AI training, biomarker discovery, or longitudinal study. IPE converts and de-identifies upstream of VNA Research (or VNA Clinical Research's research lane).

Flow

  1. 1 IRB-approved research protocol defines cohort criteria + anonymization profile
  2. 2 Qualifying slides ingested via the watch folder
  3. 3 IPE applies anonymization profile during conversion (DICOM PS3.15 Annex E + IRB overrides)
  4. 4 Anonymized DICOM WSI forwarded to VNA Research or to VNA Clinical Research's research lane
  5. 5 Cohort metadata retained for IRB renewal cycles
  6. 6 Re-identification possible via the family-wide honest-broker capability if protocol authorizes
Pattern 5

Multi-site pathology consolidation

A health-system pathology service with scanners at multiple sites (different scanner vendors at different sites) consolidates onto a unified DICOM WSI archive. IPE deployments at each site convert per-site native files; converted DICOM WSI flows to a central VNA.

Flow

  1. 1 Per-site IPE deployments handle each site's scanner mix
  2. 2 Each site's native files convert to DICOM Sup 145 locally
  3. 3 Converted DICOM WSI forwarded to central VNA via STOW-RS
  4. 4 Site-of-origin metadata preserved (source-site tag) for downstream attribution
  5. 5 Central archive serves all sites' pathologists with consistent DICOM retrieval

Integration points

Scanner formats, DICOM output, downstream targets.

Scanner-native input formats

  • Aperio SVS — Leica Biosystems GT450 / AT2 / ScanScope
  • Hamamatsu NDPI — NanoZoomer S60 / S210 / S360 / RS / XR
  • 3DHistech MRXS — Pannoramic series (now Sysmex)
  • Roche / Ventana BIF — DP200 / DP600 / DP1000
  • Leica SCN — SCN400 series
  • Zeiss ZVI / CZI — Axio Scan series
  • Pyramidal TIFF / BigTIFF — generic
  • DICOM Sup 145 — already-DICOM scanners (passthrough mode)

Output: DICOM WSI

  • SOP Class 1.2.840.10008.5.1.4.1.1.77.1.6 (VL Whole Slide Microscopy Image Storage)
  • Multi-resolution pyramid matching source levels
  • Embedded label + overview images
  • Tile-based for browser-friendly DICOMweb retrieval downstream
  • Optical-path metadata (objective, illumination, immersion)

Downstream targets

  • XyDromatics VNA Repository / Clinical / Research / Clinical Research via STOW-RS
  • Any DICOM-conformant third-party VNA via STOW-RS
  • Pathology PACS systems with DICOM Sup 145 support
  • AI-vendor endpoints for digital-pathology AI integration
  • Research archives with anonymization applied during conversion

Cross-product orchestration

  • Shared site encryption key (consistent anon-IDs across the customer's portfolio)
  • Same anonymization profiles as Router / Migration Engine / VNA Research
  • AI-vendor PHI-shielded round-trip pattern same as the rest of the family
  • SynthQMS integration for IPE configuration changes (regulated change control)

Identity, audit, observability

  • OIDC / SAML for the web admin UI
  • Active Directory / Azure AD federation
  • Per-watch-folder audit trail entries
  • Hash-chain audit log spanning ingest → convert → forward
  • Prometheus metrics + structured JSON logs
  • HIPAA-mode license state observable on /health endpoint

System requirements & sizing

Sized to slides per day.

WSI files are large (50 GB to 500 GB per slide depending on tissue size and magnification). Conversion is CPU-intensive for the multi-resolution pyramid generation. I/O bandwidth is often the bottleneck before CPU saturates. Sizing tiers are starting points; final sizing comes out of discovery.

Tier Slide volume CPU RAM Storage Typical site
Departmental < 200 slides / day 8 vCPU 32 GB 2 TB working + intake / convert Single pathology service, 1–2 scanners. Single IPE host.
Hospital pathology 200 – 1,000 slides / day 16 vCPU 64 GB 8 TB working Hospital pathology service, multiple scanners, full clinical signout workflow.
Academic medical center 1,000 – 3,000 slides / day 32 vCPU per node, multi-host 128 GB per node 20+ TB working AMC pathology service with research workload, multi-vendor scanner mix.
Multi-site enterprise > 3,000 slides / day aggregate 32 vCPU per site, distributed deployment 128 GB per node Per-site working storage + central archive Health-system multi-site pathology consolidation, per-site IPE deployments forwarding to central VNA.

Licensing

Three packages, HIPAA mode license-gated.

Core covers conversion + forwarding for research / development use. The HIPAA Mode tier unlocks clinical use (mandatory for any production pathology workflow). Enterprise adds keyed- hash, AI-vendor PHI shielding, multi-host deployment, and HA pairing.

IPE Core (research / development)

The base appliance — WSI conversion, watch-folder ingest, STOW-RS forwarding. Research / development use only without HIPAA mode license.

  • All native WSI format conversions
  • DICOM Sup 145 output with multi-resolution pyramid
  • Watch-folder ingest with per-scanner profiles
  • STOW-RS forwarding (any DICOM-conformant target)
  • Web admin UI + RBAC
  • PHI-free / non-clinical mode only

IPE + HIPAA Mode

Adds the license-gated HIPAA mode for clinical use. Required for any production clinical pathology workflow.

  • Everything in Core
  • `hipaa_mode` license feature activated
  • Clinical-use enabled (PHI handling permitted under HIPAA / 21 CFR Part 11 alignment)
  • Strict feature-license enforcement (cannot be config-toggled)
  • HIPAA-mode state observable on /health endpoint for inspection-ready evidence
  • License-status auditing per the family-wide license-feature-enforcement standing rule

IPE Enterprise

Everything, plus keyed-hash pseudonymization for AI-vendor PHI shielding, multi-host deployment, and HA.

  • Everything in Core + HIPAA Mode
  • Keyed-hash pseudonymization for AI-vendor PHI shielding
  • Built-in honest-broker capability for re-identification
  • Multi-host distributed deployment (multi-site or high-throughput)
  • Active-active HA pair
  • Cross-product site-key sharing (with Router / VNA family / SR Engine / Migration Engine)
  • Premium support tier eligible

Per-deployment licensing. Multi-host deployments licensed per-host. Multi-product bundles (IPE + VNA family + Router / Migration Engine / SR Engine) get bundle pricing and shared site-key provisioning for cross-product anon-ID consistency.

Documentation

The controlled-document set.

Every Pathology Engine deployment ships with the documents below, all managed under SynthQMS document control. The DICOM Conformance Statement is publicly available; the rest are shared under mutual NDA.

Document Title Notes
DOC-2026-060 Hardware & Software Requirements (Pathology Engine) Sizing, OS support, dependencies
DOC-2026-076 DICOM Conformance Statement (Pathology Engine) Public — VL Whole Slide Microscopy Image Storage SOP class
DOC-2026-066 EULA Annex (Pathology Engine) Annex to the Synthology Master EULA (DOC-2026-063)
DOC-2026-309 Penetration Test Results (Pathology Engine) Available under NDA
DOC-2026-052 QA Runner Manual (Pathology Engine) Internal QA + customer-validated test runs
DOC-2026-084 User Guide (Pathology Engine) Operator + administrator + pathology-IT workflows
DOC-2026-071 Installation Guide (Pathology Engine) Windows MSI deploy + OpenSlideNET dependency installation

Additional documents

Pathology Engine-specific documents beyond the standard set. Items marked Pending are tracked for authoring under SynthQMS change control.

Document Title Notes
DOC-2026-051 HIPAA Mode License-Feature Spec (Pathology Engine) Strict feature-license check + /health observability
DOC-2026-401 Per-Scanner Profile Catalog (Pathology Engine) Per-scanner known-quirk profiles maintained as living documentation

Frequently asked

The questions pathology IT asks.

Why is IPE the only Windows-only product in the family?

OpenSlideNET dependency. Whole-slide-imaging vendor formats (SVS, NDPI, MRXS, BIF, etc.) are read by the OpenSlide library, which depends on a stack of native C libraries (libtiff, libpng, libxml2, glib, vendor-specific decoders). The .NET binding (OpenSlideNET) wraps these via P/Invoke. The whole stack compiles cleanly on Windows but cross-compiling for Linux requires picking up native dependencies that aren't straightforward to package consistently. Rather than ship a partially-functional Linux build, IPE is Windows-only by design. The rest of the router-pattern family (Router, VNA family, SR Engine, Migration Engine) ships cross-platform; IPE is the deliberate exception.

What scanner formats does IPE handle?

The major vendor formats: Aperio SVS (Leica Biosystems), Hamamatsu NDPI (NanoZoomer series), 3DHistech MRXS (Pannoramic, now Sysmex), Roche / Ventana BIF (DP200 / DP600 / DP1000), Leica SCN (SCN400), Zeiss ZVI / CZI (Axio Scan series), and pyramidal TIFF / BigTIFF as a generic fallback. Already-DICOM scanners are passed through without re-conversion. The per-scanner profile catalog (DOC-controlled) tracks vendor-specific quirks per firmware revision.

What's realistic conversion throughput?

Highly dependent on slide resolution, scanner format, and host CPU. Conservative targets: a single IPE host on 16 vCPU + 64 GB RAM converts roughly 200-500 slides/day at typical clinical scan resolutions. Higher-throughput deployments use multi-host distributed processing. WSI files are large (50 GB to 500 GB per slide depending on tissue size + magnification + bit depth) so I/O bandwidth is often the bottleneck, not CPU. Discovery phase produces a realistic forecast for your scanner mix and volume.

Why is HIPAA mode license-gated rather than a config toggle?

Deliberate design control under the non-device posture (§520(o)(1)(D)). A clinical-use capability that's gated by the EULA but reachable via a config flag can be enabled by accident -- and good cybersecurity practice is not friendly to that pattern. By making HIPAA mode a license feature with strict license-status enforcement (per the family-wide license-feature-enforcement pattern), the entitlement boundary lives in code rather than in customer-modifiable config. Without a valid HIPAA-mode license, IPE force-resets to non-clinical mode at startup -- the customer can't accidentally enable a clinical capability they're not entitled to.

Can IPE forward to non-Synthology VNAs?

Yes. STOW-RS is the standard DICOM HTTP-based store endpoint, and IPE forwards to any STOW-RS endpoint -- XyDromatics VNA family, third-party VNAs, pathology-specific PACS, AI vendors. For institutions that already have a vendor VNA they're happy with, IPE slots in upstream as the WSI conversion layer without forcing a VNA replacement.

How does the AI-vendor PHI-shielding workflow work for digital pathology?

Same family-wide mechanism as the Router, VNA family, SR Engine, and Migration Engine. IPE uses keyed-hash pseudonymization on the way out (de-identifies the DICOM WSI as it forwards to the AI vendor), retains the source ↔ anon-ID mapping, and re-identifies AI-returned findings on the way back. Available in the Enterprise license tier. AI vendor sees only anonymized WSI; findings get linked to the right case in the pathology archive without the AI vendor ever receiving PHI.

DICOM WSI vs proprietary scanner formats — which is better long-term?

DICOM Sup 145 WSI is the long-term answer for vendor-neutral archiving. Proprietary formats lock the data to the originating scanner vendor; DICOM WSI travels with the patient regardless of which scanner is in service today or in fifteen years. The industry trajectory is firmly toward DICOM WSI -- pathology departments running converted DICOM WSI archives have an easier time switching scanner vendors, integrating AI, and satisfying long-term retention requirements. IPE's job is making that transition incremental rather than all-or-nothing.

What's the regulatory classification?

Non-device software under FD&C Act §520(o)(1)(D), the 21st Century Cures Act §3060 carve-out for software that transfers, stores, converts, or displays device data without interpreting or analyzing it. No FDA Device Listing required. Same framework as Router, VNA Repository, VNA Migration, SR Engine, and Migration Engine -- IPE handles storage and forwarding (format conversion is not interpretation) without modifying clinical interpretation. HIPAA mode is the license-gated clinical-use feature; the underlying classification is the same non-device carve-out.

Plan a digital-pathology deployment.

Tell us your scanner mix, slide volume, target archive, and whether you need clinical (HIPAA mode) or research-only. We’ll come back within one business day with a proposed deployment.