US-hosted PHI: what “regions” actually mean for your BAA

“We host in the United States” is a sentence that sounds complete until you ask follow-up questions. Which cloud regions? Where do backups live? Where are logs aggregated? Where do support engineers connect from when they troubleshoot? Does the AI feature send audio or text to an inference endpoint—and if so, in which region, under which subprocessors, with what retention? For PHI, vague geography is not a marketing flex; it is a liability waiting for the first diligence questionnaire from a hospital partner or a state attorney general inquiry.

This essay is a practical guide for operators and counsel: what to ask, what to write into contracts, and how to translate provider console settings into language your compliance committee can defend. It is not legal advice—but it is a map of the holes we see repeatedly.

Primary region vs. data gravity

Cloud providers sell regions as isolated failure domains. Applications still create data gravity: cross-region replication for disaster recovery, global load balancers, centralized logging, and object storage lifecycle policies that move cold data to cheaper tiers—sometimes in different regions unless you pin policies. Your vendor’s architecture diagram should show where PHI is created, where it is written durably, and where it is read.

Backups deserve special scrutiny. Snapshots often land in object storage buckets with their own lifecycle rules. If a vendor cannot tell you the bucket region and encryption key model, you do not yet have a residency story—you have hope.

Inference and subprocessors

When AI features call external APIs, the PHI boundary expands. Your BAA should name subprocessors and regions—or explicitly prohibit certain flows. If marketing says “on-device” or “private” but engineering says “we batch to a hosted model,” you have a disconnect that will eventually become an incident.

Logs, observability, and support access

Telemetry is data. PHI-adjacent logs can include identifiers in URLs, error payloads, or session IDs. Centralized logging should be region-pinned and access-controlled. Support break-glass access should be time-bound, logged, and justified—especially if offshore support is in scope.

If it is not in the contract, it is not in your compliance story.

Incident response and patient communication

Predictable residency simplifies incident response: you know which regulator framework applies, which notification clocks apply, and which customers need which communications. Ambiguous multi-region setups produce ambiguous answers under stress—exactly when you need clarity.

Checklist you can paste into a vendor questionnaire

• List all regions where PHI may reside at rest, including backups and replicas.
• Confirm whether DR failover crosses regions and whether PHI is replicated there.
• Disclose all AI subprocessors, model hosting regions, and retention for prompts/outputs.
• Describe support access paths and whether staff can view PHI, with what logging.
• Attach encryption model: who holds keys, rotation, and whether customer-managed keys are supported.

teleclinicos is built so US residency and BAA scope are explicit—not hidden behind a generic trust page. If you want to walk through a concrete architecture review for your specialty, we are here for that conversation.