Whitepaper · De-Identification Engine

Secure cross-network ingest, de-identified at the trust boundary

Research and AI programs need imaging and reports moved into a research environment — but that data starts life as PHI, and the network path between the clinical source and the research destination is exactly where exposure risk concentrates. The XyDromatics De-Identification Engine treats de-identification as a trust boundary, not a downstream cleanup step: data is accepted only over authenticated, encrypted, fail-closed channels, de-identified in place at the point of entry, and forwarded so that only de-identified output ever leaves the engine.

The re-identification key lives only on the engine. It never travels with the data, is never embedded in the output, and never crosses the wire — so downstream consumers cannot re-identify what they receive. Run the engine in Synthology’s cloud or entirely on your own infrastructure; the guarantee is identical.

DICOMweb STOW-RS ingest, DICOM-TLS on the C-STORE listener, and MLLP-over-TLS on the HL7 ORU listener are shipped and wire-roundtrip verified. All three secure channels are off by default — an on-premises deployment inside a trusted network keeps plain DIMSE/MLLP until secure transport is turned on. Burned-in-pixel and encapsulated-document redaction use a local OCR engine, never cloud OCR.

Book a demo Product overview

The problem

The research-data movement gap

Every imaging AI pilot, registry, and multi-site study begins the same way: someone has to get studies and their reports out of the clinical environment and into a research one. The clinical environment is governed by HIPAA and hospital security policy; the research environment — a cloud tenant, an external reading service, an AI vendor — is not the covered entity’s protected network. The data has to cross that gap, and that crossing is where controls thin out: PHI on the wire in cleartext; a correlation table that must be secured, retained, and eventually destroyed; de-identified datasets that are internally inconsistent between modalities; and no single, auditable point where “PHI in, de-identified out” can be proven.

The gap persists because two hard problems — moving data securely across a network, and de-identifying it usefully but irreversibly — are usually solved by different tools at different points in the pipeline. The engine collapses them into one boundary.

Dataflow

The engine is the trust boundary

Raw PHI arrives from the customer site over an encrypted, mutually-authenticated channel and is de-identified at the boundary; only de-identified output flows onward to VNA Research. The engine occupies the same position whether Synthology hosts it in the cloud or the customer runs it on-premises.

Secure cross-network de-identification ingest A customer site on the left holds the plaintext sources: a PACS or modality that speaks DICOM C-STORE, an EMR or RIS that emits HL7 v2 ORU reports, and a third-party PACS or cloud that speaks DICOMweb. Each pushes to the De-Identification Engine across an untrusted network over an encrypted, mutually-authenticated channel: DICOM-TLS C-STORE, MLLP-over-TLS, or DICOMweb STOW-RS with mutual TLS. Every channel is fail-closed — an unauthenticated or unpinned peer is rejected before any object is read. The De-Identification Engine is the single trust boundary and the only place the re-identification key lives: it pseudonymizes identifiers, interval-shifts dates, scrubs free text and burned-in pixels, and harvests standards-coded concepts. Only de-identified output leaves it, flowing to VNA Research — a Research-Use-Only de-identified archive plus a PHI-free coded-concept cohort store. The engine occupies the same trust-boundary position whether Synthology hosts it in the cloud or the customer runs it on-premises. CUSTOMER SITE SECURE TRANSIT · UNTRUSTED NETWORK DE-IDENTIFICATION ENGINE VNA RESEARCH · RUO PACS / modality DICOM C-STORE · plaintext PHI EMR / RIS HL7 v2 ORU · plaintext PHI 3rd-party PACS / cloud DICOMweb · plaintext PHI DICOM-TLS · C-STORE secure DIMSE · TLS 1.2/1.3 MLLP-over-TLS secure HL7 v2 DICOMweb · STOW-RS HTTPS · multipart Part 10 mTLS · FAIL-CLOSED · PINNED De-Identification Engine The only place the key lives Pseudonymize · interval date-shift Free-text + burned-in pixel scrub Coded-concept harvest Expert-Determination method TRUST BOUNDARY VNA Research De-identified DICOM archive + PHI-free coded cohort store Downstream HL7 sink de-identified ORU ✓ NO PHI LEAVES de-identified Encrypted, mutually-authenticated ingest (raw PHI, in transit only) De-identified output — no PHI, no key Same trust boundary, two deployments: Synthology-hosted (the engine + VNA Research run in Synthology's cloud) · or customer-operated (the customer runs the whole chain on-prem).

Secure ingest

Three secure, mutually-authenticatable channels

All three channels share the same disciplines: transport encryption via TLS 1.2/1.3, SHA-256 client-certificate thumbprint pinning available for mutual authentication, and fail-closed behavior on any credential or certificate-load failure. All three are off by default — an on-premises deployment inside a trusted network keeps plain DIMSE and MLLP, and turns secure transport on only when data must cross a network boundary. Each channel is covered by an integration test that asserts, on the receiver side, that a real object crossed intact and that a rogue peer, a missing certificate, or a wrong token is rejected fail-closed.

DICOM-TLS on the C-STORE listener

The DICOM C-STORE listener can be wrapped in TLS built from the engine’s server certificate. Mutual TLS is an operator opt-in: when enabled, the peer’s certificate is accepted only if its SHA-256 thumbprint is in the configured pin set — an empty pin set with mutual TLS on rejects every peer. If the certificate fails to load, the listener does not come up; there is no plaintext fallback. Peer identity is additionally gated by the DICOM Calling-AE allow-list, which applies with or without TLS.

MLLP-over-TLS for HL7 v2 reports

The HL7 ORU listener can wrap each accepted MLLP connection in a TLS session negotiated before the first MLLP frame is read. Mutual TLS is an operator opt-in against the same SHA-256 thumbprint-pin model. A certificate-load failure means the listener does not start — again, no plaintext fallback. When enabled, no report byte crosses a plaintext or unverified channel.

DICOMweb STOW-RS

The engine accepts POST /dicom-web/studies (multipart/related Part 10) behind a dedicated fail-closed gate that authenticates before any DICOM object is parsed — an unauthenticated request receives 401 up front. The gate is either/or: a request must present either a valid sealed bearer ingest token (compared in constant time) or a pinned client certificate. Client-certificate authentication is required by default unless a sealed bearer token is configured as the alternative; with neither credential, every caller is rejected.

Certificate paths and pinned thumbprints are non-secret configuration. Certificate passwords and the DICOMweb bearer token are reversible secrets: they are sealed at rest inside a whole-config encryption envelope and are never returned by the API — administrative surfaces expose only boolean “is-set” flags, never the values.

De-identification at the boundary

What the engine guarantees

Every object is de-identified at receipt, one-way, before it is ever forwarded. This section describes the value and the assurance level — not the internal key mechanics.

Method and assurance

The engine applies HIPAA Safe Harbor tag transforms across the 18 identifier categories of 45 CFR §164.514(b)(2), executed at every level of DICOM sequence nesting so nested PHI cannot hide below a top-level pass. Because the engine adds pseudonymization and interval-preserving date handling that go beyond pure Safe Harbor, the governing certification is a §164.514(b)(1) Expert Determination — the customer’s own determination, by a qualified expert of the customer’s choosing, not a determination rendered by Synthology.

Pseudonymization

Patient and study identifiers are replaced with deterministic keyed pseudonyms under a per-site key that never leaves the engine. Deterministic means the same input yields the same pseudonym for the life of the key, so a patient’s studies still reassemble downstream with no retained mapping table. The transformation is one-way.

Interval-preserving date shift

Dates are shifted by a per-patient whole-day offset, so inter-exam intervals and chronological order are preserved exactly while absolute dates are obscured. Time-of-day is retained; ages over 89 are handled per Safe Harbor. When a date is genuinely shifted, the object is stamped with the DICOM Attribute Modification method code (DCM 113107) and the standard PS3.15 de-identification method attributes.

The content gate

Structured tags are not the only place PHI hides. A fail-closed content gate cleans three residual risks with a per-lane clean / quarantine / reject policy: free-text SR narratives (two-pass scrubber), burned-in pixel text (irreversible pixel replacement using a local, bundled OCR engine — never cloud OCR), and encapsulated documents (PDFs rasterized, OCR-redacted, and rebuilt image-only, dropping the selectable text layer and metadata). Anything it cannot confirm clean is quarantined, never forwarded.

Cross-protocol alignment — no correlation table

Reports arriving over HL7 and images arriving over DICOM are de-identified so the same medical-record number produces the same pseudonym and the same date-shift offset on both paths. A de-identified report lands on its de-identified study’s timeline with no correlation table and in any arrival order — the alignment is a property of the computation, not of a stored map that must be secured, leaked, or destroyed.

The boundary guarantee

What leaves — and what never does

  • What leaves: de-identified DICOM (pseudonyms, shifted dates, remapped UIDs) and de-identified HL7 reports, forwarded to the research destination — an RUO de-identified archive such as XyDromatics VNA Research, a downstream HL7 research sink, and/or external consumers such as AI vendors or outside reading services, which receive pseudonymized studies only.
  • What never leaves: the re-identification key. It does not travel with the data, is not embedded in the output, and never crosses the wire. Because the output carries no key, downstream consumers cannot re-identify it.
  • In the Synthology-hosted deployment: no PHI and no re-identification key persist in the cloud — only de-identified output.

An optional coded-concept cohort capability can additionally populate a PHI-free, pseudonym-keyed store of standards-coded clinical concepts (never free-text PHI) for cohort discovery. It is opt-in, triple-gated (operator enablement, a licensed add-on, and a current §164.514(b)(1) attestation), and any cohort query resolved through the coded-concept store enforces a k-anonymity floor of k ≥ 11.

Deployment

Two models, one trust boundary

Synthology-hosted (cloud) Customer-operated (on-prem)
Where the engine runsSynthology’s cloud, alongside the research archiveEntirely inside the customer’s network
How data arrivesCustomer pushes over a secure channelLocal push; secure channels optional inside the trusted network
Re-id key custodyOn the engine only; never persists in the cloudOn the engine only, inside customer infrastructure
What persists downstreamDe-identified output onlyDe-identified output only
HIPAA relationshipSynthology as Business Associate under a BAACustomer-operated; no BAA needed for hosting

Regulatory & privacy posture

Non-device, Research Use Only

The XyDromatics De-Identification Engine is non-device software under FD&C Act §520(o)(1)(D). It transfers and converts medical-device data; it has no clinical or diagnostic function. It is not, and is not pending as, a medical device.

The de-identification method is HIPAA Safe Harbor tag transforms (45 CFR §164.514(b)(2)) whose residual re-identification risk is certified under a §164.514(b)(1) Expert Determination — the customer’s own determination by a qualified expert, not a determination by Synthology. De-identified output is Research Use Only. HIPAA obligations are separate from the software’s non-device posture: when Synthology hosts the engine, Synthology can act as a HIPAA Business Associate under a BAA.

Build your de-identified research pipeline.

Cross-network ingest to a Synthology-hosted engine, or an on-prem appliance inside your network? Tell us where your PHI starts and where your research data needs to land, and we’ll come back within one business day with a proposed architecture.

Request a demo Product page