Skip to main content
Handling PHI through AI requires an unbroken chain of Business Associate Agreements — from your organization, through HASP, to every party that touches the data. This page explains how that chain is structured and what each link covers. 
Customer (Covered Entity)
   │  signs the HASP customer BAA
   ▼
HASP (Business Associate)
   │  owns PHI handling end-to-end; routes inference under HASP-direct BAAs
   ▼
Inference providers (Sub-Business Associates)
   Anthropic — HASP Healthcare BAA
   OpenAI    — HASP Enterprise BAA
You sign one BAA with HASP. It establishes HASP as your Business Associate and is the gate for production-mode PHI usage. With no active BAA on the org, the substrate’s policy plane fails closed: PHI-flagged content is refused before it reaches any provider. Free Evaluation orgs have no signed BAA and therefore cannot submit PHI — PHI mode is forced to block. HASP integrates directly with model providers under HASP-direct BAAs, rather than proxying through a third-party gateway:
ProviderCoverageBAA
Anthropic (Claude family)hasp_anthropic_baa_2026HASP Healthcare BAA
OpenAI (GPT family)hasp_openai_baa_2026HASP Enterprise BAA
Each model in the catalog declares its BAA coverage. Inference is routed only to providers covered by a HASP-direct BAA, so the chain stays unbroken without any per-customer provider negotiation.

​
PHI handling is HASP-owned

PHI de-identification, redaction, and re-identification is a HASP-owned core substrate capability — not a function rented from a third party. It runs as a step inside HASP’s AI Gateway pipeline, above the provider-routing layer: 
Gateway → [HASP PHI scan + redact] → Driver → [Provider routing + BAA inference]
The capability is built on Microsoft Presidio, extended with healthcare-specific recognizers (MRN formats, NPI numbers, drug names, lab values, ICD/CPT codes). PHI is detected and redacted before content leaves HASP’s substrate to any inference provider, and re-identified in the response stream.
Because PHI handling lives above the provider-routing line, the original PHI is redacted before the provider ever sees it. Providers receive placeholder tokens ([NAME_1], [MRN_1], …), not the underlying values. Re-identification happens on the way back, inside HASP’s substrate.

​
What’s covered, and what’s disclosed

  • PHI handling controls are covered by HASP’s own attestation engagement — HASP attests the controls it operates rather than inheriting attestation from a third-party gateway.
  • User feedback is never forwarded upstream. Thumbs ratings and conversation feedback are stored inside HASP’s data plane only; they are never transmitted to Anthropic, OpenAI, or any provider as training signal or telemetry.
  • Anthropic flagged-abuse retention. Anthropic retains requests flagged by its abuse-detection systems for up to 2 years, outside HASP’s control. This passthrough retention obligation is disclosed in the customer BAA sub-processor exhibit and the Trust Center.

​
PHI is never persisted in audit logs

Audit rows carry the redacted form plus entity-class metadata only — for example, "SSN redacted at offset 42". Original PHI values never land in audit storage at any tier. A narrow forensic-replay path exists through a crypto-shredded, per-request re-identification map with a short dispute window (24h default), but that map is mathematically destroyed when the window closes.

​
Where the substrate sits

The provider chain is replaceable at the driver line, but the HASP-owned components above it — identity, policy, audit, and PHI handling — do not move with a provider swap. See Compliance Posture for how the BAA chain fits the broader framework coverage, and Audit Chain for how PHI events are recorded.