Cross-product capability

Bring AI to your clinical workflow — without sending PHI to anyone.

Synthology pseudonymizes patient identifiers at every cloud boundary — on‑prem to our routing tier, our routing tier to your AI vendor of choice, and back again. The customer holds the decryption keypair. Even our own engineers can’t read what flows through.

See a Live Demo See the architecture
Plaintext PHI in cloud
Never

Re-identification at on-prem only

Keypair custody
Customer

Synthology cannot decrypt

AI vendors supported
Any

Vendor-agnostic egress

Two deployment patterns

One architecture, two enterprise-grade use cases

✓ Available today

Cloud router with zero-knowledge PHI

Your on-prem Synthology Router pseudonymizes every PHI tag before any byte leaves your hospital network. The cloud routing tier handles store-and-forward, archival, and orchestration without ever holding the key needed to read what passes through. On-prem re-identifies for clinical viewing.

  • ▸Customer holds the keypair; cloud is provably blind without it
  • ▸HIPAA-defensible architecture — minimum-necessary disclosure to the cloud tier
  • ▸Drop-in replacement for cloud-PACS architectures
  • ▸Reversible (clinical) and irreversible (research) modes

Software shipping today — non-device software under FD&C Act §520(o)(1)(D), no FDA premarket clearance required.

Learn about the Router
Generally available

AI medical-vendor egress

Imaging AI for radiology, pathology, and cardiology. Clinical NLP for documentation and coding. Decision-support engines. Foundational LLMs for narrative tasks. Most of these vendors won’t sign a BAA covering protected health information — and with Synthology’s pseudonymization tier, you don’t need them to. Every identifier is stripped before the request hits the vendor’s API and re-attached when the response comes back.

  • ▸Vendor-agnostic — any HTTPS-accessible AI inference API can be a destination
  • ▸Per-request audit trail with full request/response provenance
  • ▸Re-identification only at the on-prem boundary
  • ▸Token-safe — vendor API keys held in customer-side escrow, never in the cloud routing tier
Book a demo View our white paper
Architecture

How it works

Pseudonymization runs at three boundaries in your network: on-prem ingress, cloud egress, and AI-vendor egress. Each boundary uses the same per-customer keypair architecture; customer-managed escrow keeps the keys out of Synthology’s reach.

Pseudonymization architecture flow Three swimlanes: Your network on the left holds your modality, the Synthology Router with the customer keypair, and the radiologist workstation. Synthology Cloud in the middle holds the cloud routing tier and explicitly carries no key. AI Medical Vendor on the right represents any third-party AI service — imaging AI, clinical NLP, decision support, foundational LLM, or specialty workflow. Step 1 sends pseudonymized payloads from on-prem to cloud; Step 2 forwards them on to the vendor and receives a response; Step 3 returns to on-prem where the same keypair re-identifies plaintext for the radiologist. YOUR NETWORK SYNTHOLOGY CLOUD · UNDER BAA AI MEDICAL VENDOR EMR / PACS / Modality DICOM · HL7 · FHIR (plaintext PHI) Synthology Router Customer keypair lives here Pseudonymize · Re-identify · Audit Radiologist workstation Receives plaintext · cloud never does Cloud routing tier Routes · archives · calls vendors ✕ NO CUSTOMER KEY HERE Synthology employees with full cloud access cannot decrypt without your keypair. AI Medical Vendor Imaging AI · Clinical NLP · LLMs · Decision support Sees pseudonyms — never PHI PHI plaintext Step 1 pseudonymized + encrypted Step 2 pseudonymized request vendor response Step 3 still pseudonymized re-identified plaintext Outbound (pseudonymized) On-prem (re-identified plaintext) Vendor response (pseudonymized)
Step 1 — Inbound

On-prem ingress

Your modality, EMR, or PACS sends DICOM/HL7/FHIR to the on-prem Synthology Router. PHI tags are replaced with reversible pseudonyms, encrypted with your customer keypair. Audit log records the transformation with hash-chain integrity.

Step 2 — Transit

Cloud routing tier

Pseudonymized payload flows to Synthology’s cloud tier. We orchestrate routing, archival, ML/AI vendor calls, observability — all without the customer keypair. Even an internal Synthology employee with full cloud access cannot decrypt without your keys.

Step 3 — Outbound

Re-identification

On the way back to your network, the on-prem Router re-identifies using the same keypair. Pathology viewer, EMR, or radiologist workstation receives plaintext — the cloud never does.

Pseudonymized data with a re-identification key in customer custody is still PHI under HIPAA — we operate the cloud routing tier under a Business Associate Agreement. The architectural difference: a Synthology BAA covers transit and storage of pseudonymized data only; we are contractually and technically incapable of producing plaintext PHI.

vs. the cloud giants

Why customer-controlled pseudonymization beats trust-the-cloud

AWS HealthLake and Azure Health Data Services are HIPAA-eligible — but their architecture leaves your PHI inside the cloud provider’s reach. Synthology’s pseudonymization layer changes the threat model.

Capability AWS HealthLake Azure Health Data Services 3verest Synthology
Customer holds the decryption key No (AWS-managed KMS by default) Optional (customer-managed key) Customer-controlled (healthcare host) Always (per-customer keypair)
Cloud provider can read plaintext PHI Yes (under their BAA) Yes (under their BAA) No (hosting platform; not a tenant of your data) No (architecturally incapable without your key)
Use AI vendors that don’t sign your BAA Bedrock only (in-cloud) Azure OpenAI only (in-cloud) Open (you deploy any compatible AI integration) Any (generally available)
Vendor lock-in High (AWS-only) High (Azure-only) None (open hosting) None (pluggable destinations)
ISO 13485-aligned firm No No No (infrastructure host) Available today (Non-device software, FD&C Act §520(o)(1)(D))
DICOM-native + HL7 / FHIR / X12 FHIR-only FHIR + DICOMweb Customer-deployed stack All four (router + VNA)

AWS HealthLake and Azure Health Data Services are managed AI/data services. 3verest is a healthcare-specialized hosting platform; the column reflects deployment flexibility rather than a turnkey managed service. Synthology supports deployment on customer-chosen infrastructure including 3verest as a hosting partner.

Comparison reflects publicly documented features as of 2026-Q2. AWS, Azure, and 3verest are trademarks of their respective owners.

Common questions

FAQ

Does Synthology need a BAA with us? ▾

Yes. Pseudonymized data with a re-identification key in customer custody is still PHI under HIPAA, and we operate the cloud routing tier under a standard BAA. The architectural difference vs. cloud providers: our BAA obligations cover transit and storage of pseudonymized data only — we are contractually and technically incapable of producing plaintext PHI on subpoena because we don’t hold the key.

What happens if we lose our keypair? ▾

Pseudonymized data flowing through the cloud becomes irrecoverable. This is the same trade-off as any customer-managed-key architecture (BYOK on AWS / Azure). We strongly recommend customer-side escrow with a hardware-security module or Vault-backed secret store and documented key-rotation procedures — we can help you stand these up.

Can we use this with our existing PACS / VNA / EMR? ▾

Yes. The Synthology Router is a drop-in DICOM/HL7/FHIR egress. Existing modalities, PACS, VNA, EMR, and downstream archives connect unchanged — the pseudonymization happens in the Router, transparent to upstream and downstream systems.

How does this compare to anonymization? ▾

Pseudonymization is reversible — clinical workflows need this so radiologists can identify the patient when reading. Anonymization is irreversible — the right choice for research data sets and AI training corpora. Synthology’s router supports both modes; we use anonymization for the Research tier and pseudonymization elsewhere.

Is the AI-vendor egress feature available? ▾

Available now. Custom integrations are available — reach out via the contact form. The architecture supports any HTTPS-accessible AI inference API: imaging AI, clinical NLP, decision support, foundational LLMs, specialty workflow engines. Synthology is in active conversations with vendors across these categories; the initial published vendor list will be the set we’ve validated end-to-end with each vendor’s BAA posture and de-identification readiness.

Ready to bring AI to your imaging stack?

Schedule a 30-minute call. We’ll walk through the pseudonymization architecture against your current cloud-PACS or AI-pipeline plans and show you a live demo on real DICOM traffic.

Request a Demo Read our regulatory posture