Bringing Healthcare AI to PHI — without the compromise
Healthcare organizations want the best AI medical vendors for their clinical and operational workflows: imaging AI for radiology and pathology, clinical NLP for documentation and coding, decision-support engines, foundational LLMs for narrative tasks, specialty workflow automation. Today they face a hard choice: lock into the small subset of vendors that sign a HIPAA Business Associate Agreement, or stay out of the market entirely because the AI vendor that solves their problem won’t sign one.
Synthology AI-Vendor Egress removes the choice. Your on-prem Synthology Router pseudonymizes every PHI element before any byte leaves your hospital network. The pseudonymized request flows through a Synthology cloud routing tier — operating under our BAA — to the AI vendor of your choice. The response returns the same way, and the on-prem Router re-identifies it for the radiologist, clinician, or care team. The cloud never sees plaintext PHI. The vendor never sees plaintext PHI. Only your network does.
The customer-keypair architecture, DICOM-side reversible pseudonymization, hash-chained audit trail, and on-prem Router infrastructure are shipping in production — and the AI-vendor egress flow (cloud routing tier, HL7/FHIR pseudonymization, free-text PHI detection, vendor adapters) is now generally available.
Two compromises healthcare organizations make today
LLMs and clinical-grade ML models are increasingly the table-stakes capability for radiology, prior authorization, clinical-documentation improvement, coding assistance, structured-report generation, and dozens of other healthcare workflows. The vendors building those models are not, for the most part, willing to operate as Business Associates under HIPAA. Some offer BAA-eligible enterprise tiers; many do not. Capabilities and contractual posture change quarter by quarter.
Compromise 1 — Cloud lock-in
Lock into a cloud’s BAA-eligible AI roster (Azure OpenAI, AWS Bedrock, Google Vertex). The most common path. The cost: vendor lock-in (you cannot use a competing model that isn’t on that cloud’s menu), single-vendor risk (a model deprecation, a price change, a policy shift is non-negotiable), and continued plaintext PHI exposure inside the cloud provider’s perimeter — under their BAA, but still inside their reach.
Compromise 2 — Sit it out
Don’t use the AI. Forgo workflows your competitors are deploying because the model you actually want isn’t BAA-eligible. This is increasingly an unsustainable position as patient and physician expectations rise.
Neither compromise is satisfying. Both are increasingly common.
The AI vendor doesn’t need to see real PHI to do its job
It needs to see structurally faithful text. A radiology report with patient names replaced by reversible token pseudonyms, MRNs replaced by reversible IDs, and dates shifted by a per-patient offset still produces an excellent impression summary. A prior-auth narrative with provider names tokenized still drafts well. The model gets what it needs; the patient identity stays in your network.
The keypair lives only in your environment — today, on the on-prem Router host (DPAPI machine scope on Windows, or AES-GCM under a deployment-managed KEK on Linux). Customer-managed HSM and cloud key-vault providers are targeted for general availability. If Synthology’s cloud were entirely compromised tomorrow, the attacker would obtain pseudonymized data and the encryption envelopes around it; without your keypair, the data is mathematically unrecoverable.
Four boundaries, one consistent story
Pseudonymization at the edge
Your modality, EMR, or PACS sends DICOM, HL7, or FHIR over your existing integration. The on-prem Synthology Router intercepts the relevant fields and applies pseudonymization rules:
- [Shipping] DICOM tags — PatientName, PatientID, AccessionNumber, ReferringPhysiciansName, InstitutionName, and the broader PHI tag set per PS3.15 §E (Basic Application-Level Confidentiality Profile, with reversibility added) are replaced with reversible pseudonyms. Dates are shifted by a per-patient deterministic offset.
- [GA] HL7 segments — PID, MSH, OBR, OBX identifier fields are pseudonymized.
- [GA] FHIR resources — Patient.name, identifier, Practitioner.name, and corresponding identifier slots in encounters, observations, and reports.
- [GA] Free-text PHI — patient names, MRNs, dates of birth, addresses, and phone numbers detected inside narrative text are tokenized in place. The free-text pipeline combines regex matching with healthcare-tuned named-entity recognition; precision/recall benchmarks against published gold-standard healthcare corpora are published with the GA release.
Pseudonyms are deterministic in context: the same patient identifier in two requests produces the same pseudonym. Pseudonyms are per-customer salted: the customer keypair is the HMAC key, so a pseudonym derived from your data cannot be linked to a pseudonym derived from another Synthology customer’s data, even if both sets are leaked. The re-identification map — the bidirectional table that lets the on-prem Router reverse the transformation — never leaves your environment.
Transit without keys
Pseudonymized payloads flow to the Synthology cloud routing tier over a Cloudflare-fronted TLS connection. The cloud tier is a thin orchestration layer with three responsibilities: receive the pseudonymized request and identify the destination vendor; apply the appropriate per-vendor request transformer; forward, capture the response, return.
By design, the cloud tier holds no copy of your customer keypair, no copy of the pseudonymization map, and no plaintext PHI. AI-vendor API keys live in customer-managed escrow and pass through encrypted-at-rest with your keypair; the cloud tier holds them as ciphertext blobs only. Synthology operates the cloud routing tier under a BAA with you, and we make a precise contractual claim: our BAA covers transit and storage of pseudonymized data only; the cloud routing tier is contractually and technically incapable of producing plaintext PHI from cloud-side state.
Vendor-side capabilities preserved
The cloud tier calls the AI vendor over the vendor’s standard API surface. Pseudonymized request arrives; pseudonymized response returns. Whether the vendor processes a DICOM study, a clinical note, a coded encounter, or a free-text prompt, the architecture preserves vendor-side capabilities:
- ▸No-training-data flags. Where the vendor offers a setting that excludes your data from their training pipeline, our per-vendor configuration documents the setting your administrator must apply on the vendor side.
- ▸Streaming responses. For vendors that support streaming, the cloud tier streams chunks back to your on-prem Router, which re-identifies and streams to your workstation.
- ▸Specialty modalities. Imaging vendors that consume DICOM studies, NLP vendors that consume HL7/FHIR, decision-support engines that consume coded data — the pseudonymization rules apply symmetrically across all of them.
- ▸Tool / function calling. For LLM vendors, pseudonymization applies symmetrically to tool inputs and outputs.
Vendors that won’t sign a downstream BAA-style instrument with Synthology are not routable. The vendor allowlist is the regulatory boundary, gated by a SynthQMS administrative permission, and every change is audit-logged.
Plaintext only at your boundary
[Shipping] DICOM-side re-identification is shipping today. Pseudonymized studies that arrive back at the on-prem Router are decrypted using your keypair, the embedded PHI map is consulted, and real patient names, MRNs, dates, and identifiers are substituted back. Plaintext is delivered to the originating workstation, EMR, or PACS.
[GA] For AI-vendor responses, the same pattern applies: vendor responses return through the cloud tier (still pseudonymized) and arrive at your on-prem Router; the Router uses your keypair to re-identify and deliver plaintext.
[Shipping]
Every re-identification event is recorded in the audit log with
timestamp, user, session, request and response hashes, and
operational metadata. The audit log is hash-chained at the on-prem
Router using SHA-256 over a canonical serialization of each row.
Synthology provides a POST
/api/audit-log/verify endpoint that walks the entire chain
and surfaces tamper detection.
Five readers, five different reasons to care
You can say “yes” to a clinical workflow your radiologists or clinicians are asking for, while honestly answering an audit committee that no PHI ever reaches the AI vendor’s servers.
Your clinical-documentation-improvement and coding-assist tools land on the latest models, not just the BAA-eligible subset offered by your primary cloud vendor.
Send DICOM Structured Reports to specialty-grading services or research-grade ML models without giving up control of patient identity.
Per-request audit trail showing what was sent to which vendor, when, by whom, and what came back. The trail is hash-chained at the on-prem Router; tamper detection is built in.
Multi-vendor AI strategy without committing to a single cloud’s roster, with procurement leverage when vendor pricing or capability shifts.
What this architecture protects against — and what it doesn’t
We’re explicit about both. Here’s the threat model.
A Synthology employee with full operational access to the cloud routing tier obtains, at most, pseudonymized payloads and ciphertext envelopes. Without your keypair — which never leaves your environment — they cannot decrypt or re-identify anything.
If an AI vendor suffers a breach exposing the prompts or studies they have processed for you, the attacker obtains pseudonymized data. Without your re-identification map (held in your environment, not theirs), the attacker cannot link pseudonyms to real patients.
Same outcome as the cloud-side insider: pseudonymized payloads + ciphertext envelopes are not recoverable PHI.
A pseudonym from your data cannot be linked to a pseudonym from another Synthology customer’s data, even if both sets are leaked. The customer keypair is the HMAC key for pseudonym generation; pseudonyms from different customers are cryptographically independent.
The vendor allowlist is gated by an administrative permission. Every change is audit-logged. An ordinary user cannot route data to a new vendor on their own.
If an adversary has root on the host running the on-prem Router, they have the keypair and the pseudonymization map. This is true of any encryption architecture; the architectural job ends at the boundary of your administered network.
A credentialed insider with appropriate workflow access cannot be defeated architecturally. Audit logs make malicious activity discoverable; they do not prevent it.
If a vendor agrees to no-training-data settings and violates the agreement, that’s a vendor-side breach — we can document it for you and exclude the vendor going forward, but cannot guarantee vendor-side behavior.
HIPAA posture
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 distinction from AWS HealthLake or Azure HDS is not that we exit HIPAA’s scope — we don’t — but that our BAA covers transit and storage of pseudonymized data only, and the cloud tier is technically incapable of producing plaintext PHI from cloud-side state.
If your use case requires fully de-identified data (research datasets, public-health reporting), Synthology’s Research VNA tier offers irreversible anonymization — that’s a separate product, with a different architectural posture, addressing a different problem.
Vendor-agnostic by design
The architecture treats every AI vendor as an HTTPS-accessible inference endpoint. The pseudonymization rules are agnostic to what the vendor does with the request. That means the same egress tier supports the full range of medical AI vendors a healthcare organization might want to use:
Imaging AI
Radiology AI for chest X-ray, CT, MR, and ultrasound interpretation. Pathology AI for whole-slide image analysis. Cardiology AI for echo, cardiac MR, and ECG. Dermatology, ophthalmology, and other imaging specialties. Pseudonymization runs at DICOM-tag granularity.
Clinical NLP
Clinical-documentation improvement, computer-assisted coding, structured-data extraction from free text, prior-authorization narrative generation, scribe assistance. Pseudonymization handles HL7 / FHIR identifier fields plus free-text PHI inside narrative content.
Decision support
Risk stratification, protocol selection, predictive analytics for sepsis or deterioration, drug-interaction checking, evidence-based guideline matching. Pseudonymization preserves coded clinical content while obscuring patient identity.
Foundational LLMs
General-purpose large language models for narrative summarization, query answering, and unstructured workflow tasks. Streaming responses, function/tool calling, and chat history are preserved symmetrically across the pseudonymization boundary.
Specialty workflow AI
Peer review, quality measures, prior authorization, claim adjudication assistance. Often hybrid endpoints that combine structured-data inputs with narrative outputs.
On-prem inference
For organizations that prefer air-gapped end-to-end, the same architecture supports local inference servers. Pseudonymization isn’t strictly required when the model never leaves your network, but the consistent operational pattern (audit, policy allowlist, key custody) applies anyway.
A small initial vendor list, expanding as we validate
Synthology is in active conversations with AI vendors across all of the categories above. Our published vendor list grows as we confirm, for each vendor, three things:
- The vendor’s API surface is stable enough to support a long-lived integration.
- The vendor is willing to operate with pseudonymized inputs — some inference pipelines have downstream dependencies that don’t tolerate token-substitution well, and we want to know that before a customer learns it the hard way.
- The vendor will sign a downstream BAA-style instrument with Synthology, OR the architectural posture is acceptable to your compliance officer without one (vendor-by-vendor).
We’re intentionally not publishing a roadmap of named vendors yet. Vendor-side BAA posture, no-training-data settings, and de-identification readiness are moving targets that change quarter by quarter. The list we publish will be the list our customers can actually run, validated end-to-end.
Adding a new vendor is a small engineering effort. Once a vendor’s API surface and BAA posture are confirmed, the per-vendor adapter is typically a few days’ work. If your organization has a preferred vendor in mind, tell us — customer-driven prioritization is how the list grows.
Coming up: SIIM 2026
We’ll be at the Society for Imaging Informatics in Medicine annual meeting and conducting structured vendor conversations across the imaging-AI ecosystem. If you have a vendor you’d like us to evaluate for the program, reach out before the show and we’ll fold it into our agenda.
How this compares
AWS HealthLake and Azure Health Data Services are HIPAA-eligible — but their architecture leaves your PHI inside the cloud provider’s reach. The architectural difference is structural, not contractual.
| 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) |
| 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) | ISO 13485-aligned (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.
AWS, AWS HealthLake, Azure, Azure Health Data Services, Azure OpenAI, AWS Bedrock, Google Vertex, OpenAI, 3verest, and other named products are trademarks of their respective owners and are referenced for comparison purposes only. Synthology is not affiliated with or endorsed by any of them. Comparison reflects publicly documented features as of 2026-Q2.
What ships when
A single-place answer to “what’s available?” Components in production today are tagged Shipping or GA; a few forward-looking items are tagged Roadmap.
| Component | Status | Target |
|---|---|---|
| Per-customer keypair generation, escrow, distribution | Shipping | — |
| HMAC-SHA256 deterministic pseudonyms with per-customer salting | Shipping | — |
| AES-256-GCM PHI envelope embedded in DICOM private group | Shipping | — |
| Reversible DICOM-tag pseudonymization (PS3.15 §E + reversibility) | Shipping | — |
| Per-patient deterministic date shift | 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 | No FDA premarket required |
| HL7 segment pseudonymization (PID, MSH, OBR, OBX) | GA | — |
| FHIR resource pseudonymization | GA | — |
| Free-text PHI detection (regex + healthcare-tuned NER) with published benchmarks | GA | — |
| Cloud routing tier under BAA | GA | — |
| AI-vendor adapter framework + allowlist | GA | — |
| Streaming responses + function/tool calling preservation | GA | — |
| Customer-managed HSM / cloud key-vault providers | Roadmap | Planned |
| End-to-end latency benchmarks (target: <200 ms p99) | Roadmap | Benchmarks publishing |
Forward-looking Roadmap targets reflect current development plans; feature sets and timing may change. Items tagged Shipping or GA are in production today and verifiable in your environment after deployment.
FAQ
Is pseudonymized data still PHI? ▾
Under HIPAA, yes. A pseudonymized dataset with a re-identification key held by the original custodian is still PHI; only Safe Harbor or Expert Determination de-identification (irreversible) removes data from HIPAA’s scope. The architectural difference Synthology offers is not that we exit HIPAA — we operate the cloud tier under a BAA — but that we are technically incapable of producing plaintext PHI inside our cloud, regardless of what the BAA permits.
What happens if Synthology’s cloud is compromised? ▾
The attacker obtains pseudonymized payloads and ciphertext envelopes. Without your keypair, no re-identification is possible. We don’t claim the cloud is unbreachable; we claim that a breach of our cloud cannot expose plaintext PHI, because plaintext PHI is never in our cloud.
What happens if I lose my keypair? ▾
You lose the ability to re-identify any future vendor responses. Existing data in your environment remains intact (the re-identification map is held by you, not Synthology). We strongly recommend customer-side HSM custody, regular key-rotation procedures, and offline cold-storage of recovery material. Detailed key-management guidance is part of customer onboarding.
Can I use multiple AI vendors at the same time? ▾
Yes. Per-feature-flag vendor selection is the default: radiology AI on one vendor, prior-auth drafting on another, coding-assist on a third — all simultaneously. The routing is configured per workflow in the SynthQMS administrative UI, and a workflow can be re-routed to a different vendor without code changes.
What’s the latency overhead? ▾
Target: <200 ms p99 added latency for typical radiology-report-sized payloads (~5 KB). Free-text PHI detection adds the bulk of this; pseudonymization itself is sub-millisecond. The on-prem Router runs adjacent to your existing integration infrastructure, so there is no additional network hop.
Does Synthology see my prompts and responses? ▾
Synthology’s cloud routing tier sees pseudonymized prompts and responses — as ciphertext envelopes that we route, log, and observe for operational metrics. We do not see plaintext PHI. We have neither the keypair nor the pseudonymization map; we cannot produce plaintext even if compelled to. This is by architectural design, and we’d rather not have to.
How do I evaluate this in my environment? ▾
Synthology offers guided evaluation engagements: run the architecture in production with real-vendor calls and full instrumentation. You receive engineering and clinical-workflow support throughout the evaluation, with pricing aligned to your rollout goals. Contact us to discuss whether your organization is a fit.
What does pricing look like? ▾
Pricing is aligned with vendor usage patterns — the dominant cost component for most customers is the underlying AI-vendor cost, not the Synthology layer. We will publish standard pricing at general availability; the design-partner program operates on a different commercial model. Reach out for specifics.
Talk to us
If you’re evaluating an AI workflow currently blocked by a vendor’s lack of BAA, or you’ve taken a single-cloud lock-in compromise that you’d like to undo, the fastest path is a 30-minute call with our solutions engineering team. We’ll walk through your specific workflow and the pseudonymization rules that would apply, and tell you within that call whether the architecture is a fit for your problem.
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 Q2 and is subject to change as products, vendor partnerships, and regulatory posture evolve.