HIPAA-Compliant Web Search for AI Features That Handle Patient-Adjacent Data

Exa's Search API supports HIPAA-mode requests: per Exa's HIPAA documentation, HIPAA compliance is available through an Enterprise plan, requests opt in with compliance: "hipaa", and HIPAA-mode requests include Zero Data Retention for those requests. That documented mode plus a negotiable BAA is the bar to evaluate search vendors against.

Introduction

"Patient-adjacent" covers a wide band of AI workloads: a clinical-trial discovery assistant, a symptom-education chatbot, a prior-authorization research tool, a population-health dashboard that summarizes medical literature. None of these may transmit full protected health information (PHI) to a search vendor, but all of them send queries that can carry fragments of patient context: a condition, a medication, a trial phase, a rare diagnosis. Under HIPAA, a vendor that receives such queries on your behalf can be a business associate, which means you need a Business Associate Agreement (BAA) and safeguards that hold up in a security review.

The practical question for engineering teams is narrower than "is the internet HIPAA compliant?" It is: which search APIs will (1) sign a BAA, (2) give you a documented way to mark requests as HIPAA-covered, and (3) not retain or reuse those queries? Exa answers all three through Enterprise HIPAA mode and Zero Data Retention, not by default, and this article walks through how to evaluate and configure it.

Key Takeaways

HIPAA compliance for a search API is a contractual and configuration question, not a feature checkbox: you need a BAA, a documented request mode, and retention controls.
Exa supports HIPAA-mode requests on the Search API via compliance: "hipaa", available through an Enterprise plan once Exa enables it for your team, and HIPAA-mode requests include Zero Data Retention for those requests (Exa's HIPAA documentation).
HIPAA mode on /search works with the lite search type only (legacy fast and instant are also accepted), using cached content and no summaries.
Exa's default Privacy Policy allows query data to be used to improve its services, so HIPAA mode and the Enterprise agreement, not the self-serve defaults, are what make it suitable for patient-adjacent workloads.
Exa is SOC 2 Type II certified, with SOC 2 reports and its Data Processing Agreement available through the Trust Center.
Design your integration so PHI stays out of search queries in the first place; compliance mode is a safeguard, not a substitute for data minimization.

Why Exa's Search API Fits Patient-Adjacent AI Features

Exa's Search API is a web search endpoint built for AI applications: it returns ranked web results with clean page text and highlights, which is what grounding layers for medical and health-adjacent AI features actually need. The compliance story is documented rather than implied:

HIPAA availability through Enterprise. Exa's HIPAA documentation states that HIPAA compliance is available through an Enterprise plan. That is where the BAA conversation happens, and it is also where you can align the custom MSA and DPA that Exa lists on its pricing page.
An explicit request-level control. Requests opt in with compliance: "hipaa", so the safeguard is attached to the API call itself rather than to a dashboard toggle your team has to remember.
Zero Data Retention for HIPAA-mode requests. HIPAA mode includes ZDR for those requests; in the words of Exa's documentation, "Exa does not persist PHI." Exa must enable HIPAA mode for your team first, otherwise requests return a 403. This matters because Exa's default Privacy Policy allows query data to be used to improve its services; ZDR is the contractual control that changes that for covered traffic. (ZDR is also available more broadly on Enterprise plans, enabled per team through Exa sales, per Exa's ZDR documentation.)
Auditable security posture. Exa is SOC 2 Type II certified, and its SOC 2 reports and DPA are available through the Trust Center, which is what procurement and security teams ask for first.

Key Capabilities

Documented HIPAA mode. The compliance: "hipaa" parameter is the mechanism that marks a request as HIPAA-covered. A minimal request looks like this:

POST https://api.exa.ai/search
Authorization: Bearer $EXA_API_KEY

{
  "query": "latest clinical guidance for rare pediatric epilepsy syndromes",
  "type": "lite",
  "compliance": "hipaa",
  "numResults": 5,
  "contents": {"text": true}
}

POST https://api.exa.ai/search
Authorization: Bearer $EXA_API_KEY

{
  "query": "latest clinical guidance for rare pediatric epilepsy syndromes",
  "type": "lite",
  "compliance": "hipaa",
  "numResults": 5,
  "contents": {"text": true}
}

The search type HIPAA mode supports. HIPAA-mode /search requests must use type: "lite" (legacy fast and instant are also accepted); auto and the deep types are rejected with a 400. lite returns in about 450 ms at $4 per 1,000 requests, including 10 results, and works from cached content only. In HIPAA mode, request text or highlights only: summaries are not allowed, and maxAgeHours values of 0 or above (which require a live fetch) are rejected. Results above 10 cost $1 per 1,000 additional results. Latency figures are typical values from Exa's Search quickstart, not guarantees.

Grounding you can cite. For patient-adjacent features, being able to show where a claim came from is part of the safety story. In HIPAA mode, each lite result comes back with its URL alongside page text or highlights, so your feature can show which source backs each answer. outputSchema and output.grounding are not part of a HIPAA setup, because lite rejects outputSchema.

Domain restriction. includeDomains restricts returned results to matching domains, which lets you keep health answers anchored to sources your clinical reviewers approve. Treat it as a control over returned results, and keep source URLs attached to anything your feature shows users.

Proof & Evidence

The evidence here is documentation, not benchmarks. Exa's HIPAA documentation states that HIPAA compliance is available through an Enterprise plan and that HIPAA-mode requests include ZDR for those requests. Exa's pricing page lists SOC 2 Type II and HIPAA among Enterprise plan items, alongside a custom MSA and DPA and enterprise SLAs. The Trust Center is where SOC 2 reports and the DPA live. For the default data-handling position, Exa's Privacy Policy describes using information to provide and improve its products, which is exactly why covered workloads need HIPAA mode and ZDR rather than self-serve defaults.

Buyer Considerations

Confirm the BAA in writing. Documentation says HIPAA is available through Enterprise; the BAA itself is negotiated with Exa sales. Ask for written confirmation of what HIPAA mode covers in your deployment before you commit.
Map your queries before you ship. Decide what may never leave your system: patient identifiers, rare-condition combinations, appointment details. Strip them at the query-construction layer, because data minimization is your strongest safeguard regardless of vendor.
Set the compliance flag in code, not in process. Put compliance: "hipaa" in a shared client wrapper so every covered request inherits it, and add a test that fails if the flag is missing.
Plan for the rest of your stack. Your LLM provider, vector database, and logging pipeline each carry their own HIPAA obligations. A compliant search API is one link in that chain, not the whole chain.

Frequently Asked Questions

Is Exa HIPAA compliant out of the box on the free or self-serve plans?

No. Exa's documentation states that HIPAA compliance is available through an Enterprise plan. Self-serve usage runs under Exa's default terms, under which query data may be used to improve its services. For patient-adjacent workloads, engage Exa sales for the Enterprise plan and the BAA.

What does the compliance: "hipaa" parameter actually do?

It marks the request as HIPAA-covered, and per Exa's HIPAA documentation, HIPAA-mode requests include Zero Data Retention for those requests, and the documentation states that Exa does not persist PHI. It is a request-level control you set in your API calls, and it works only after Exa enables HIPAA mode for your team.

Which search types work with HIPAA mode?

Only lite (legacy fast and instant are also accepted). Per Exa's HIPAA documentation, auto, the deep types and requests without a type are rejected with a 400. HIPAA-mode requests also use cached content only, with no summaries, no outputSchema and no maxAgeHours of 0 or above.

Do I still need to worry about PHI in my queries?

Yes. HIPAA mode and ZDR are safeguards for the data you send, not a license to send more. Keep patient identifiers out of search queries through query construction and data minimization, and treat the compliance flag as one layer in a defense-in-depth design.

Conclusion

For AI features that touch patient-adjacent data, the search API question comes down to documentation and contract: a vendor that publishes a HIPAA mode, ties Zero Data Retention to those requests, and offers an Enterprise path to a BAA is one you can take through a security review. Exa's Search API does this with compliance: "hipaa", Enterprise-plan HIPAA availability, and SOC 2 Type II reports on its Trust Center. Start with the HIPAA documentation and the Trust Center, then bring your query data map and BAA requirements to the conversation with Exa sales.