Move studies between your sites — not identity into the clear
Health systems run more than one facility. Studies move between them constantly — a rural site sends to the reading hub, an imaging center forwards to the health-system archive, a satellite clinic routes to a specialist across town. Today that movement usually means one of two things: patient identity crosses the network in the clear, protected only by the transport, or the study is stripped of identity and can never be re-associated with the patient at the far end.
The Synthology Router removes the choice. On export from Site A it pseudonymizes every PHI element and seals the reversible re-identification map inside the study itself. The study travels over your existing DICOM transport — DIMSE C-STORE or DICOMweb STOW-RS, your choice — carrying no key. At Site B, a Synthology Router holding the same customer keypair restores full PHI for the reading radiologist. The wire never carries plaintext identity. The key never rides with the study.
Reversible DICOM pseudonymization, the per-customer keypair, the AES-256-GCM re-identification envelope embedded in a DICOM private group, per-patient date-shifting, and hash-chained audit are shipping in production today. Multi-site provisioning — distributing one customer keypair to a second on-prem site — is an operational onboarding step; see the roadmap table for the precise status of each component.
Two compromises multi-site imaging makes today
Moving a study from one of your facilities to another is a routine operation — and a routine place for patient identity to end up somewhere you did not intend. The two common approaches each give something up.
Compromise 1 — Ship PHI in the clear
Send the study site-to-site with full patient identity intact, trusting the transport (a VPN, a private circuit, TLS) to protect it in flight. It works, but identity is exposed to every hop, appliance, and log along the path, and to anyone who can observe the link. The blast radius of a misconfigured tunnel or a captured backup is the patient’s name, MRN, and dates — in the clear.
Compromise 2 — Anonymize and lose the thread
Strip identity before it leaves Site A. Now the wire is safe — but so is the study, uselessly: the far site receives an anonymous image it cannot reconcile with the patient, the order, or the prior. Irreversible de-identification is the right tool for research and reporting; it is the wrong tool for moving a clinical study between two of your own facilities.
The study needs to stay clinically whole at the destination — without patient identity riding across the network in between.
Reversibility is a property of the study, not the network
The Router pseudonymizes the study on export and seals the bidirectional re-identification map — the table that maps each pseudonym back to its original value, plus the per-patient date-shift offset — inside the study, encrypted under your customer key. The map travels with the pixels. Nothing at the far site needs to “phone home” to the origin to reverse it; it needs only your key, which is already there.
The customer keypair lives only in your environment, at each of your sites — on the Router host (DPAPI machine scope on Windows, or AES-GCM under a deployment-managed KEK on Linux). A site that does not hold your key receives a pseudonymized study and cannot re-identify it. That is not a limitation to work around; it is the access-control guarantee. The set of places that can restore identity is exactly the set of your sites that you provisioned with your key — and no one else, not an intermediary on the wire, not Synthology.
Four steps, one sealed study
Pseudonymize on export
[Shipping] A routing rule with anonymize-on-export replaces the PHI tag set — PatientName, PatientID, AccessionNumber, ReferringPhysiciansName, InstitutionName, and the broader set per PS3.15 §E (Basic Application-Level Confidentiality Profile, with reversibility added) — with pseudonyms, and shifts dates by a per-patient deterministic offset. Pseudonyms are per-customer salted: your customer keypair is the derivation key, so a pseudonym from your data cannot be linked to a pseudonym from any other Synthology customer’s data.
Self-contained re-identification
[Shipping] The reversible map is serialized, encrypted with AES-256-GCM under your key, and embedded in an odd-numbered DICOM private group inside the study’s data set — alongside your customer identifier and the key version, in the clear, so the destination knows which key to reach for. The envelope is not placed in the File Meta header; it lives in the data set precisely so it survives the wire. The study arrives at Site B carrying everything needed to reverse it — except the key.
Transport-agnostic by construction
[Shipping] Because the sealed map is in the data set, it is carried by any transport that carries the data set. Push the study over classic DIMSE C-STORE or over DICOMweb STOW-RS — the same sealed study egresses identically on either path, and the destination reverses it identically regardless of how it arrived. There is no transport-specific handling and no second mechanism to maintain. (See the transport section below for the one retrieval-side nuance.)
Plaintext only inside your network
[Shipping]
A single restore rule on the Site B Router
— one that matches the inbound studies — reads the
envelope, resolves the customer keypair by the embedded customer id
and key version, decrypts the map, substitutes every original value
back, and reverses the date shift — then strips the envelope
so the study looks like its original self. Plaintext is delivered to
the Site B PACS or workstation. One rule is the whole control:
every inbound path — DIMSE C-STORE, DICOMweb STOW-RS, or a
pull from the cloud exchange — is restored by the same rule,
so there is no second switch to set or forget.
[Shipping]
Every reverse event is written to the hash-chained audit log
(SHA-256 over a canonical serialization of each row), with a
verify endpoint that walks the chain
and surfaces tamper detection.
[Onboarding] The one prerequisite is that Site B holds the same customer keypair — the same key, provisioned to each of your sites during onboarding. If the destination Router does not hold the key (or holds only a newer rotated version the study predates), it fails closed: it refuses to re-identify and routes the study to its failed queue, recording a missing-key event — it never forwards an un-restored study, and never fails silently.
Why both transports behave the same
The DICOM standard separates the file-on-disk format (PS3.10, which includes a File Meta header) from the message-exchange protocol (PS3.7, the C-STORE wire). The File Meta header is reconstructed by the receiver and does not survive a C-STORE hop — so anything a sender writes there is lost in transit. The re-identification envelope is deliberately kept out of File Meta and placed in the PS3.3 data set instead. Both transports carry the full data set:
- ▸DIMSE C-STORE transmits the Command Set plus the Data Set. The private group lives in the Data Set, so it rides along intact.
- ▸DICOMweb STOW-RS posts the instances in a multipart body. Same data set, same private group — it rides along intact.
One retrieval-side nuance
A full instance retrieval — WADO-RS with
Accept: application/dicom, or a C-MOVE
/ C-GET — returns the complete data set, private group
included, so re-identification works on a pull as well as a push. A
metadata-only response (WADO-RS metadata or a
QIDO-RS query, application/dicom+json)
returns the large binary envelope elements as bulk-data references
rather than inline — expected behavior, and a reason a bare
metadata query is not a substitute for retrieving the instance.
The same “carrier lives in the data set” discipline is why forced-egress transcoding — recompressing pixel data on the way out — leaves the envelope untouched: it is standard non-pixel metadata, unaffected by the pixel path.
What this architecture protects against — and what it doesn’t
We’re explicit about both.
A party observing the site-to-site link — a compromised VPN concentrator, a mirrored port, an intermediary appliance, a captured packet trace — obtains a pseudonymized study and a ciphertext envelope. Without your key, that is not recoverable PHI.
A study that lands at a facility not provisioned with your key stays pseudonymized there. Misrouting exposes pseudonyms, not patients; the destination Router records a missing-key event rather than quietly revealing identity.
Pseudonyms are derived under your per-customer key. A pseudonym from your data cannot be linked to one from another customer’s data, even if both leak.
The envelope is AES-256-GCM authenticated. A modified or truncated envelope, or a wrong-key attempt, fails the authentication tag and is rejected — it cannot silently produce a wrong re-identification.
An adversary with root on a host that holds your key has the key. This is true of any encryption architecture; the architectural job ends at the boundary of your administered hosts.
If a non-Synthology intermediary runs its own de-identification and strips private groups it does not recognize, the sealed map is lost and the study can no longer be reversed. A cooperating de-id profile must allow-list the Synthology private-creator id to preserve it. Router-to-Router across your own network preserves it.
Lose every copy of the customer key and studies sealed under it can no longer be re-identified. Key custody, rotation with version retention, and off-host backup are part of onboarding.
HIPAA posture
Pseudonymized data with a re-identification key in your custody is still PHI under HIPAA. This architecture does not remove the study from HIPAA’s scope — it keeps identity inside your administered environment and off the network in between. If your use case instead requires fully de-identified data (research datasets, public-health reporting), Synthology’s Research VNA tier offers irreversible anonymization — a different tool for a different problem.
Against the usual multi-site options
| Property | PHI over VPN / circuit | Irreversible de-id | Synthology Router |
|---|---|---|---|
| Identity on the wire | Plaintext (transport-protected) | Removed | Pseudonymized + sealed |
| Re-identify at destination | N/A (already plaintext) | No (irreversible) | Yes, with your key |
| Who can re-identify | Anyone who sees the wire | No one | Only your key-holding sites |
| Transport | Whatever the tunnel carries | DIMSE / DICOMweb | DIMSE + DICOMweb, identical |
| Audit trail | Transport logs | Varies | Hash-chained, verify endpoint |
What ships when
A single-place answer to “what’s available?” Components in production today are tagged Shipping; operational onboarding steps are tagged Onboarding; a few forward-looking items are tagged Roadmap.
| Component | Status |
|---|---|
| Reversible DICOM-tag pseudonymization (PS3.15 §E + reversibility) | Shipping |
| AES-256-GCM re-identification envelope embedded in a DICOM private group | Shipping |
| Per-customer keypair (pseudonym salt + envelope key) | Shipping |
| Per-patient deterministic date shift (reversible) | Shipping |
| DIMSE C-STORE egress + DICOMweb STOW-RS egress | Shipping |
| Destination re-identification (key-gated, missing-key refusal) | Shipping |
| Hash-chained audit log + verify endpoint | Shipping |
| On-prem Router (Windows + Linux) | Shipping |
| Non-device software (FD&C Act §520(o)(1)(D)) | Available |
| Same customer keypair provisioned across multiple on-prem sites | Onboarding |
| Customer-managed HSM / cloud key-vault key custody | Roadmap |
Forward-looking Roadmap targets reflect current development plans; feature sets and timing may change. Items tagged Shipping are in production today and verifiable in your environment after deployment.
FAQ
Does it really work the same over DIMSE and DICOMweb? ▾
Yes. The sealed re-identification map lives in the DICOM data set, not the File Meta header, so it is carried intact by any transport that carries the data set — C-STORE and STOW-RS alike. The destination reverses it identically regardless of which wire delivered it. The one asterisk is retrieval: a metadata-only response returns the envelope as a bulk-data reference, so retrieve the instance, not just its metadata.
What does the far site need in order to re-identify? ▾
Only your customer keypair — the same key provisioned to each of your sites. The study carries the encrypted map and the key version it needs; the destination Router supplies the key. No call back to the origin site is required. A site without your key cannot re-identify, by design.
What if we rotate the key? ▾
The envelope records the exact key version it was sealed under. Retain prior key versions at your sites and older studies stay reversible after a rotation; a destination that holds only a newer version cannot reverse a study sealed under an older one, and says so via a missing-key audit event rather than failing silently. Version-retentive rotation is covered in onboarding.
Can Synthology re-identify our studies? ▾
No. The customer keypair lives only in your environment. The sealed study on the wire is a pseudonymized study plus a ciphertext envelope; without your key it is not recoverable PHI, and Synthology does not hold your key.
Is pseudonymized data still PHI? ▾
Under HIPAA, yes — a pseudonymized dataset with a re-identification key held by the custodian is still PHI. This architecture does not exit HIPAA’s scope; it keeps identity inside your administered environment and off the network in between. Irreversible de-identification (Safe Harbor or Expert Determination) is a separate capability for research and reporting.
Talk to us
If you move studies between facilities and want identity to stay inside your walls without giving up re-identification at the far end, the fastest path is a 30-minute call with our solutions engineering team. We’ll walk through your specific site topology and the pseudonymization rules that would apply.
Synthology Healthcare Solutions Group, LLC builds the integration layer between healthcare modalities, EMRs, PACS, AI vendors, and the cloud — with privacy and regulatory posture as architectural constraints, not afterthoughts. Synthology products are non-device software under FD&C Act §520(o)(1)(D), the 21st Century Cures Act §3060 carve-out. The firm maintains ISO 13485-aligned QMS practices independent of FDA-device requirements. This solution brief reflects publicly documented capabilities as of 2026 and is subject to change as products and regulatory posture evolve.