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.
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.
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)
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.
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
1Pathology scanner produces native WSI file (SVS / NDPI / MRXS / etc.) into the watch folder
2IPE detects file completion, identifies the format
3Conversion to DICOM Supplement 145 WSI with multi-resolution pyramid generation
4Per-slide tag normalization (accession-number format, study description, etc.)
5STOW-RS forward to target VNA
6Audit 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
1Existing scanner-native files staged in batch ingest folders
2IPE processes in scheduled windows (overnight / weekend) at controlled parallelism
5Per-slide audit trail proves what was converted and when
6Original 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
1Slide qualifies for AI analysis per institutional policy
2IPE de-identifies via keyed-hash pseudonymization (anon-ID derived from PHI + system encryption key)
3De-identified DICOM WSI sent to AI vendor (vendor sees only anon-ID)
6Findings 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
1IRB-approved research protocol defines cohort criteria + anonymization profile
2Qualifying slides ingested via the watch folder
3IPE applies anonymization profile during conversion (DICOM PS3.15 Annex E + IRB overrides)
4Anonymized DICOM WSI forwarded to VNA Research or to VNA Clinical Research's research lane
5Cohort metadata retained for IRB renewal cycles
6Re-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
1Per-site IPE deployments handle each site's scanner mix
2Each site's native files convert to DICOM Sup 145 locally
3Converted DICOM WSI forwarded to central VNA via STOW-RS
4Site-of-origin metadata preserved (source-site tag) for downstream attribution
5Central archive serves all sites' pathologists with consistent DICOM retrieval
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.
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.