PHI on the Line — and How The Clinician Platform Makes Choice & Compliance Possible

---

Framing the Problem

Every healthcare AI conversation eventually collapses into the same false binary: cloud or on-premise, buy or build. That framing skips the part that actually determines whether a deployment succeeds — what the model is being asked to do, and what happens to the patient data on the way there.

A model that drafts a clinician-facing summary from a full longitudinal chart has a different risk profile than one extracting a medication list from a single note. A health system with a mature cloud compliance program is in a different starting position than a service with an in-country data-residency mandate or an air-gap requirement.

This document lays out three real architectures for running an LLM against patient data, then shows how TCP lets you adopt all three — chosen per task — behind a single governed control point.

---

The PHI / PII Issue, Stated Plainly

Large language models are extraordinary at clinical text — and clinical text is dense with protected health information: names, identifiers, contact points, dates, free-text history. The moment a prompt is assembled, PHI/PII is in motion. Three failure modes follow:

• Data crossing a boundary it shouldn’t. A managed model API may move PHI outside your network, your tenancy, or your jurisdiction — a non-starter for some IRBs, government programs, or residency rules unless a Business Associate Agreement (BAA) explicitly covers that specific product and configuration. Note that while HIPAA does not mandate US data residency, institutional policies and international frameworks (like GDPR) often do [7] [8].
• BAA coverage that is narrower than assumed. An enterprise contract with a model provider is not automatically a HIPAA contract. Consumer tiers, developer playgrounds, and beta features are routinely excluded — even when a BAA exists elsewhere in the same relationship [1] [2].
• The unauthorized surface breach. While large-scale hacking incidents dominate headlines [3], the most pervasive unmanaged risk in AI adoption is "shadow IT"—such as a clinician pasting a patient chart into an unauthorized, consumer-tier LLM. A BAA or an air gap is necessary, but never sufficient. The system must prevent the data from reaching the unauthorized surface in the first place [4].

The conclusion the rest of this document builds on: the deciding factor is a technical control layer that (1) keeps PHI off the wrong surface, (2) removes or minimises PHI before any external hop where it isn’t needed, and (3) routes each request to the model that fits the task — with one consistent audit trail no matter where inference runs.

---

Option One: Frontier general-purpose models, accessed by API under a BAA

What it is: A frontier foundation model — OpenAI, Google Gemini, or a managed hyperscaler tier (AWS Bedrock, Google Vertex AI, Azure OpenAI) — consumed through a hosted API, with PHI in scope only where a BAA actually covers that specific product and configuration.

⚠️ A critical compliance pitfall: The compliant path is usually a specific API tier, a specific enterprise configuration with HIPAA explicitly enabled, or routing through a hyperscaler’s BAA rather than the model provider directly — not whatever surface is easiest to reach.

---

Option One B: Frontier models via provider-native regional endpoints

What it is: The same frontier models as Option One — OpenAI GPT-4-class, Anthropic Claude, Google Gemini — but accessed through provider-native regional API endpoints that pin inference and data storage to a specific geography. This is an emerging but rapidly maturing tier, rolled out explicitly to address data sovereignty requirements and to reduce inference latency for users outside North America.

As of 2025–2026, all three major frontier providers and their hyperscaler wrappers have launched or expanded regional endpoint programmes:

• OpenAI launched European data residency for the API Platform in February 2025, expanded to the UK, Japan, Canada, South Korea, Singapore, Australia, India, and the UAE by October 2025, and added in-region GPU inference (not just at-rest storage) for eligible enterprise customers in January 2026 [10]. Eligible API customers create a region-scoped Project in the dashboard; requests through that Project are handled in-region with zero data retention by default.
• Anthropic Claude exposes an inference_geo parameter on the API (supported on Claude Opus 4.6, Sonnet 4.6, and later) that pins inference to US-only or global infrastructure per request. US-pinned inference is priced at a 1.1× multiplier. Workspace-level policies can restrict which geos are permitted, enforcing residency at the platform layer rather than per-call [11].
• Azure OpenAI offers three deployment tiers — Global, Data Zone (EU or US boundary), and Regional — giving teams a sliding scale from maximum model availability to strictest in-region processing. The EU Data Boundary commitment covers Azure OpenAI for most data types, and provisioned throughput units (PTUs) can be reserved per region [12].
• AWS Bedrock exposes per-region endpoints for all supported model families. Cross-Region Inference is an explicit opt-in; geographic profiles (US, EU, APAC) keep routing inside a chosen boundary, and service-control policies can deny calls to disallowed regions [7].
• Google Vertex AI provides regional endpoints for Gemini models with explicit residency commitments per region, and in April 2026 made multi-region endpoints for Claude on Vertex AI generally available — automatically balancing traffic within a single geography (e.g., between EU regions) without crossing jurisdictional boundaries [13].

⚠️ Critical caveats that apply equally here: Regional endpoint availability is per-model and per-feature — not every model variant ships to every region, preview features often carry weaker residency guarantees than GA features, and auxiliary surfaces (prompt caching, evaluation, observability telemetry) may still route globally unless explicitly pinned. A residency review must audit all six data surfaces, not just the inference endpoint [7]. BAA scope remains the same as Option One: confirm the specific regional configuration is covered before processing PHI.

---

Option Two: General-purpose open-weight models, self-hosted on local hardware

What it is: Compact local AI accelerators with unified CPU/GPU memory — enough to load genuinely large open-weight models, sitting inside your own walls.

🔍 What the spec sheet doesn’t tell you: The headline compute number describes capacity, not speed. The real governor is memory bandwidth, which on this class sits well below a high-end discrete GPU — creating a real, measurable token-generation gap on larger models [5].

---

Option Three: Distilled or quantized models, on the same local hardware

What it is: The same hardware class, but a model deliberately chosen for speed — a distilled 7B–14B model, or an aggressively quantized version of a larger one — sized to fit comfortably inside a modest memory bandwidth budget.

---

Architecture Comparison: A Decision-Maker’s Summary

---

Other Architectures Worth a Serious Look

General-purpose architectures that don’t fit neatly into the three buckets above — and the two TCP implements natively.

💡 Worth comparing: Evaluate several general-purpose models side-by-side rather than assuming one provider is the automatic pick — pricing, regional availability, and BAA terms shift often enough that last year’s comparison is probably stale.

---

Don’t Pick One Architecture. Segment by Task.

The strongest deployments don’t bet the organisation on one posture — they make the local-vs-cloud call per task, based on what the task actually needs.

• High-value, low-volume, high-complexity reasoning — US-based or global data — prior auth, claims appeals, clinician-facing summarisation → a BAA-covered frontier model (Option One).
• High-value reasoning with residency constraints — same task types as above, but data bound to GDPR, the Australian Privacy Act, or equivalent frameworks → a provider-native regional endpoint (Option 1B): frontier quality, no hardware, contractual in-region commitment.
• High-volume, narrow, repetitive tasks — de-identification, structured extraction, intake triage → a local open-weight or distilled model (Option Three).
• Strict air-gap or data that must never leave the building — patient data subject to the most restrictive residency or security requirements → a fully self-hosted model on your own hardware (Option Two).

Segmenting by task is the right answer — but only if something can enforce the segmentation and prove it after the fact. That something is the platform.

---

How The Clinician Platform Makes Choice & Compliance Possible

TCP places a single governed gateway between every platform service and every model. No clinician and no service talks to a model directly. Each request is authenticated, attributed, optionally de-identified, then routed — by policy — to the model that fits the task, wherever that model is hosted. Where de-identification is applied, TCP re-constitutes the original PHI/PII in the response before it is returned to the calling service, so the clinician’s experience is seamless and contextually complete — while no protected information left the boundary. Every call lands in one audit trail.

This is precisely the “hybrid cascade” and “orchestration layer with routing” the framework above calls for, made native: choice (any of the three architectures, per task) and compliance (de-identification, residency control, and auditability) are properties of the gateway, not of each calling service.

Each platform service enters through a single governed gateway. After authentication and attribution, PHI/PII is de-identified before any external hop — only anonymised text reaches a managed API. TCP re-constitutes the original PHI/PII in the model response before returning it to the calling service, preserving a seamless clinician experience while ensuring no protected information crossed the boundary. The policy-driven router selects the appropriate model backend based on task type, data class, and residency requirements. Every call — regardless of destination — is recorded in one unified audit trail.

Choice — the same request, any of the four architectures

The router selects a model by policy, keyed to the task and the data class. The calling service doesn't need to know which model is handling the request, nor manage API keys, nor handle fallback logic.

Compliance — how the controls map to the PHI framework

Framework principle (Part one)	TCP capability (Part two)
Stop PHI reaching the wrong surface	A single governed gateway is the only path to any model — there is no direct, ungoverned route to paste a chart into.
Minimise PHI before an external hop (hybrid cascade)	Automated PHI/PII detection & redaction runs in-line before managed-API calls, so only de-identified text leaves the boundary. TCP then re-constitutes the original PHI/PII in the model response before returning it to the calling service — preserving a seamless clinician experience while ensuring no protected information crossed the external boundary.
Respect BAA scope & data residency	Policy pins residency-constrained data to a sovereign in-region endpoint or a self-hosted model; managed-API routes are limited to BAA-covered configurations.
Segment by task	The policy-driven router chooses the model class per request — frontier, sovereign, or self-hosted — without changing the calling service.
Attribution & accountability	Every request is authenticated to a known platform service and tagged; access is granted per service, not blanket.
One consistent audit trail regardless of where inference runs	Model, token usage, latency, calling service, and data class are written to a single audit store for every call — local, sovereign, or cloud.
Avoid provider lock-in / access risk	Adding or swapping a backend is a policy change behind the gateway; callers are unaffected, so a throttled or deprecated provider can be re-routed centrally.

---