The Solution: Questa Anonymizer + Blackbox in the Clinical Workflow
Here's the architecture I recommend to every hospital IT team, and it's the same pattern regardless of which AI model (closed or open source) you standardize on:
EHR / Clinical System → LLM Gateway → Questa (tokenize PHI) → AI Model (ChatGPT, Claude, Gemini, Copilot) → Response → Questa (re-identify for the authorized clinician) → EHR / Clinical System
The clinician's prompt — "Summarize this patient's cardiac history and flag drug interactions" — still contains the patient's real chart data. Before it leaves your network boundary, Questa Anonymizer detects and tokenizes the name, MRN, date of birth, address, and any other PHI entity, replacing each with a realistic, structurally consistent placeholder. The model reasons over the anonymized clinical context — it still understands that a value is a patient name or a date, it just never sees the real one — and generates its response. Questa AI then reverses the tokenization automatically, so the clinician sees the complete, real answer. The AI vendor's logs, the API provider, and anyone downstream of the model never had access to the raw PHI at any point.
For health systems that can't accept any data leaving their network boundary — a common requirement for the largest hospital systems and payer-owned provider groups — Questa Blackbox runs the entire anonymization and re-identification layer self-hosted, air-gapped inside your own infrastructure. Nothing about the anonymization step touches Questa's cloud at all; you own the deployment end to end.
For engineering teams building the clinical assistant itself rather than buying it off the shelf, the Questa Privacy MCP server exposes this as a direct tool call: anonymize_document takes a chart export, a PDF discharge summary, or inline prompt text and returns sanitized content plus an entity map, while commands like redact_pii handles inline text like a transcribed clinician note. Because it's MCP-native, it plugs directly into Claude and into Cowork-style agent workflows without custom middleware — the same privacy-first processing pattern I use on Questa's own documents can sit in front of a Slack-based clinical triage bot or a custom GPT action just as easily as it sits in front of a full EHR integration. That is the value of an MCP-based integration: privacy controls can be introduced as a reusable step in an AI workflow rather than rebuilt separately for every model interface. Whether the overall deployment meets HIPAA requirements still depends on the complete technical and administrative control environment.
For the parts of the stack outside anonymization — where the tokenized data actually lives, and how it's stored long-term — I'd point health systems to Bubl Cloud, one of our infrastructure partners, which flips the usual cloud model: instead of your data traveling out to a shared cloud service, the compute comes to your data inside an encrypted, European-hosted vault. Paired with Questa's tokenization layer, that gives a hospital system a full answer to "where does patient data live, and who can see it, at every stage."
Why This Beats the Alternatives
Redaction tools that only work on static documents — the PDF discharge summary, the scanned intake form — solve half the problem. They don't touch the live conversation between a clinician and an AI assistant, which can be a significant point of PHI exposure in AI-enabled workflows. And relying on your AI vendor's own privacy policy is not a technical control: privacy terms from an AI provider should not be treated as a substitute for the hospital's own risk assessment and technical safeguards. Questa is built specifically to sit in that gap — in the live request path, not just on the document at rest — which is also why it's priced as usage-based infrastructure rather than a fixed per-seat redaction license: Questa's commercial terms and comparative costs should be presented using current, verifiable pricing and a clearly defined comparison methodology. Avoid percentage savings claims unless they can be supported by named competitors, equivalent usage assumptions, and dated pricing evidence.
