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.

​
The chain

You sign one BAA with HASP. It covers your organization whether you sign as a covered entity or as a business associate building your own product for covered entities: in the first case HASP acts as your Business Associate; in the second, HASP acts as your Subcontractor under 45 CFR §164.502(e)(1)(ii), and the same agreement serves as the required written subcontractor agreement. Each party contracts one link only — the BAAs between you and the covered entities you serve are yours to hold, and HASP’s provider BAAs (Link 2) are HASP’s. Either way the HASP BAA 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: 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:
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.