OpenAI for Healthcare: Is the API HIPAA Compliant?

"Can we use OpenAI with patient data?" is one question that is really three: which OpenAI products a BAA covers, what the agreement obliges OpenAI to do, and whether that is enough for your workload.

This post answers all three from OpenAI's own documentation.

The short answer

Yes, the OpenAI API can be used with PHI once two conditions are met. Your organization needs an executed BAA, and your account needs to be provisioned with the right retention configuration. The BAA alone is not sufficient.

That distinction matters, because most teams assume that signing the agreement is the whole step.

Which products a BAA actually covers

OpenAI's help center lists the eligible products by name:

OpenAI makes the following HIPAA eligible products available with a Business Associates Agreement (BAA): ChatGPT for Healthcare / ChatGPT for Enterprise with Regulated Workspace / ChatGPT FedRAMP / ChatGPT for Clinicians / API with Modified Retention / API FedRAMP with Modified Retention

Two exclusions matter in practice:

• Consumer ChatGPT is not on that list, and neither is ChatGPT Business. OpenAI states plainly: "We do not offer a BAA for ChatGPT Business."
• The API is eligible only "with Modified Retention." OpenAI's own wording: "HIPAA eligibility for the OpenAI API is contingent on Customer's account being provisioned with Modified Retention."

So "is OpenAI HIPAA compliant" has no single answer. It depends which surface you are using and how that surface is configured.

How to get the API agreement

OpenAI runs a self-serve flow for the API. The steps, per their help center:

1. Sign in to the API Platform and select the organization.
2. Open Settings → Organization → General.
3. Under HIPAA compliance support, select Enable.
4. Review the Business Associate and Healthcare Addendum, confirm your authority to accept it, and select Agree and enable.

Two conditions catch people out. Self-serve enrollment "requires an established history of API usage," and you must be an organization admin with authority to accept the agreement on the organization's behalf. If you need custom terms, OpenAI takes requests at baa@openai.com and reports a 1-2 business day response.

One operational detail worth knowing before you begin: once enabled, "you cannot disable it in the API Platform settings."

What happens to the data

OpenAI's data-controls documentation is unusually specific here, and it is worth reading in full before you design around it. The relevant controls:

Both Modified Abuse Monitoring and Zero Data Retention require prior approval from OpenAI. ZDR does not cover everything either: the docs note that some endpoints "may still store application state, even if Zero Data Retention is enabled."

There is a counterintuitive point worth stating clearly. With a BAA plus Private Retention or Safety Retention, OpenAI says BAA-eligible endpoints "can be used for processing PHI, even if data is retained." PHI handling on OpenAI does not strictly require zero retention. It requires the agreement and the right endpoint.

The limitation OpenAI states itself

I would rather quote this than write my own version, because it applies to every vendor in this space, including us:

Accepting a BAA and enabling HIPAA compliance support do not, by themselves, make your application HIPAA compliant. You are responsible for evaluating your use of the services and meeting your compliance obligations.

A BAA is a prerequisite, not a compliance program. You still own your access controls, your safeguards, and your audit trail.

Pricing

Representative API prices at the time of writing, standard tier and short context, per million tokens:

Longer-context and regional endpoints cost more. OpenAI applies a 10% uplift to regional processing endpoints for models released on or after March 5, 2026, and to FedRAMP endpoints.

For comparison, current open-weight rates on our catalog run from $0.14/M input and $0.28/M output for DeepSeek-V4-Flash-Vision-Exp, to $3.00/M input for Kimi K3. That is the gap the rest of this post is about.

Where OpenAI is genuinely the right choice

• You need GPT-class models specifically. We do not serve closed-source frontier models today (this is coming soon!). If your product depends on one, OpenAI is the answer for now.
• Your workload never touches PHI. Internal tooling, documentation, code generation - no BAA needed, and the frontier models are excellent at it.
• You already have an enterprise agreement. The self-serve path requires API usage history, but an existing enterprise relationship smooths it.

Where a BAA-backed open-weight API is the right choice

• Your workload is clinical. At that point you are choosing a compliance posture, not just a model.
• Cost compounds. A token-price difference of 10x is a rounding error at 10 million tokens and a budget line at 10 billion.
• You want model portability. Open weights can be moved between providers. A hosted closed model cannot.
• You want one compliance surface. One BAA, one retention posture, one audit trail, rather than a chain of subprocessors to document.

The decision rule

Ask two questions, in this order.

First: does the workload touch PHI? If not, OpenAI is a strong default and the rest of this does not apply. If it does, you need the BAA and the retention configuration before you write the first prompt - not after.

Second: which model do you actually need? If it is a closed frontier model, OpenAI is the vendor. If an open weight will do the job - and for summarization, extraction, classification, and drafting it usually will - then you are paying a premium for capability you are not using.

If you want the unified-API pattern with the legal instrument attached, OpenMed Router provides a signed BAA, zero-retention isolated inference, and AES-256 encryption in transit and at rest, across the open-weight catalog. Proprietary models are coming soon to the same platform. The HIPAA compliance guide sets out what a valid AI BAA has to mandate.

Working through a HIPAA decision on OpenAI? Join the waitlist.