Designing HealthCare AI workflows to minimize BAA exposure

The problem: BAA review slows HealthCare AI

A recurring implementation pattern is straightforward: the engineering team builds a promising AI workflow, then procurement and privacy review slow the rollout while the organization evaluates the vendor’s HIPAA posture, data retention, and contracting path.

Here is the current contracting landscape:

• Consumer tiers are not HIPAA-ready and should be treated as out of scope for PHI.
• OpenAI and Anthropic now offer BAAs for certain commercial configurations, subject to case-by-case review and HIPAA-ready service scope.
• Azure OpenAI may be a simpler contracting path for organizations already operating inside Microsoft enterprise terms and healthcare compliance programs.
• The real bottleneck is still diligence—data flows, retention, logging, and scope need to be nailed down before PHI touches an external model.

The commercial point is still real: if your architecture can safely reduce or eliminate PHI disclosure to third parties, you shorten the review surface. But that is very different from assuming the BAA question disappears by default.

The insight: minimize the PHI that leaves

HIPAA’s definition of a Business Associate requires that the vendor “creates, receives, maintains, or transmits” Protected Health Information on behalf of a covered entity.

The key word is “transmits.”

If the downstream service never receives PHI because the transmitted payload has been de-identified before disclosure, the legal analysis changes materially. But tokenization or redaction is not enough on its own. You still need to test whether the payload remains identifiable in context and whether any retained mapping makes the data effectively re-identifiable.

The implementation: four steps

Step 1: intercept

Deploy a sidecar proxy in your Kubernetes cluster and explicitly route the outbound LLM API calls that are in scope:

# Route OpenAI traffic through GLACIS sidecar
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
spec:
  egress:
    - to:
      - podSelector:
          matchLabels:
            app: glacis-sidecar

Step 2: detect & redact

The sidecar runs a RegexSet-based PHI detector that identifies and replaces sensitive data with tokens:

// Before redaction
"Patient John Smith (DOB 03/15/1985) presents with..."

// After redaction
"Patient [PHI_NAME_1] (DOB [PHI_DATE_1]) presents with..."

Step 3: ephemeral vault

In this pattern, original PHI values are held in a memory-only vault with a TTL matched to the request timeout and cleared after the response. The implementation, crash behavior, swap policy, telemetry, and backup paths still need verification.

Step 4: cryptographic attestation

For a request routed through the configured sidecar path, a signed record can bind reported redaction counts, an outcome, a timestamp, and declared scope. It does not prove that every request was captured, that the remaining payload is no longer PHI, or that no data crossed another system boundary:

{
  "attestation_id": "att_7x9k2mNp...",
  "phi_detected": 3,
  "phi_transmitted_reported": 0,
  "scope": "configured-sidecar-path",
  "timestamp": "2025-12-01T14:32:00Z",
  "signature": "ed25519:..."
}

The legal analysis

The key question is whether a vendor that never receives PHI qualifies as a Business Associate. Under 45 CFR § 160.103, a Business Associate is defined as a person or entity that “creates, receives, maintains, or transmits” PHI on behalf of a covered entity.

If PHI is stripped before transmission and the downstream service only ever sees data that no longer qualifies as PHI, the argument improves. But it is not automatic:

• HIPAA turns on the data actually disclosed — if the external vendor receives PHI, the BAA analysis is unavoidable.
• De-identification is the stronger framework — HHS guidance under 45 CFR § 164.514 matters more here than the conduit exception.
• HHS treats the conduit exception narrowly — OCR’s cloud-computing guidance says it applies only to pure transmission services with no storage other than temporary storage incident to transmission.
• A de-identified downstream payload changes the analysis — OCR separately says a cloud service provider is not a business associate if it receives and maintains only information that has been de-identified in accordance with the Privacy Rule.
• Vendor configuration matters — OpenAI and Anthropic now provide BAAs for certain HIPAA-ready services, which may be cleaner than trying to force a non-covered workflow into a narrow legal theory.

Primary sources

• 45 CFR § 160.103
• 45 CFR § 164.514
• HHS: Guidance on de-identification of PHI
• HHS: Guidance on HIPAA and cloud computing
• HHS OCR FAQ: de-identified information and CSP status
• OpenAI Help Center: API BAA guidance
• Anthropic Help Center: BAA guidance

What this enables

With this architecture in production, healthcare organizations can now deploy:

• Clinical documentation assistants that summarize patient encounters
• Prior authorization automation that drafts appeals
• Patient messaging copilots that help clinicians respond faster
• Quality improvement analytics that identify care gaps

Potentially with less PHI disclosure, tighter retention boundaries, and clearer evidence for internal review.

Try it yourself

If you are building AI features that touch patient data and a deal is stuck in security review, review the evidence-pack approach, then bring us the action that’s holding the deal up.