Using OpenAI and LLM APIs in HIPAA Apps
Search "is OpenAI HIPAA compliant" and you'll get a hundred answers written for someone who isn't you. Most are written for the privacy officer deciding whether staff can use ChatGPT, or the clinician wondering if pasting a note into a chatbot is allowed. Useful, if that's your job. But if you're the one wiring an actual API call into a health app, a yes-or-no doesn't tell you what to build.
The short version: you can absolutely ship AI features in a HIPAA app. Compliance here is a sequence of steps, and none of them happen by default. Pick the right product tier, sign the BAA, call only the endpoints that can carry patient data, and put a PHI-safe pipeline around the call. Get those four right and you're most of the way there.
This is about your application calling an LLM programmatically. A human typing into a chat window is a different problem with a different answer, and we cover that one separately.
Can you use OpenAI and other LLM APIs in a HIPAA-compliant app?
Yes, on four conditions. Use a BAA-eligible product tier (the OpenAI API, ChatGPT Enterprise, or ChatGPT for Healthcare, never consumer ChatGPT), sign the BAA and get your organization provisioned, route patient data only through eligible endpoints like chat/completions and responses, and wrap the call in a PHI-safe pipeline covering redaction, retention controls, output handling, and an audit trail. Azure OpenAI, Anthropic Claude, Google Vertex AI, and AWS Bedrock all sign BAAs through their own mechanisms.
Key Takeaways:
- The product tier decides everything before the code does. Consumer ChatGPT, Claude Pro, and Google AI Studio are never BAA-eligible, and self-serve ChatGPT Business is the trap that catches otherwise careful teams. Only the API and sales-managed enterprise tiers can lawfully touch patient data.
- A signed BAA covers the vendor's side of the line and nothing else. Your inputs, prompt logs, output storage, and the observability and analytics tools in between stay your responsibility, and each of those tools needs its own BAA when telemetry carries PHI.
- store:false stops response persistence and nothing more. Only an approved account-level control keeps your content out of abuse-monitoring logs, and Zero Data Retention also forces store to false on every request.
- Only a subset of endpoints can carry PHI. Chat/completions and responses are the only two you can use for patient data with retention under the BAA. Assistants, Threads, Vector Stores, Files, Batch, and Fine-tuning retain application state until you delete it, and enabling ZDR doesn't change that.
- HIPAA-eligible is not HIPAA-compliant. The vendor grants eligibility. You build compliance yourself, out of architecture, configuration, and an audit trail, and that's where most failures happen after the paperwork is signed.
Why every health app now has an LLM problem
In early 2026, 81% of US physicians reported using AI in their practice, up from 38% in 2023, per the AMA's latest survey. "AI" is doing a lot of work in that number, but the fastest-growing uses are clinical documentation and summarization, both generative: a model reading and writing clinical text. For anyone building software for healthcare providers, shipping an AI feature is just the baseline now.
You know the features. Ambient scribes that draft the visit note. Intake bots that triage before the appointment. Summarizers that squeeze a chart into a few lines. Prior-auth drafting that turns a payer's criteria into a submission.
Real products, all of them, and the money points the same way: AI-enabled companies took 54% of US digital-health venture dollars in 2025, up from 37% the year before, by Rock Health's count.
The part that turns a feature into a compliance decision is the plumbing underneath it. That feature runs on an LLM API. HIPAA cares about one thing here: patient data left your walls, and running it through an AI model doesn't change the obligation.
So the moment your app sends a chart note to a model, two things are true at once:
- You've handed regulated data like protected health information (PHI) to a third party, a business-associate event whether or not anyone scoped it that way.
- Whatever that third party retains or logs is now your compliance problem too.
And the exposure is real. Across genAI-related data-policy-violation incidents in healthcare, regulated data like PHI turned up in 89% of them, per Netskope's 2026 healthcare report. That figure is the makeup of those violations, how much of the leaked data was regulated, rather than the share of organizations that had one. When data leaks in health software, it's overwhelmingly patient data leaking.
The tell is that careful teams build around all this. We've had prospects show up with the compliance rules written into the build spec before a single feature ships:
- store:false on every chat completions call
- PHI limited to eligible endpoints
- nothing sensitive in prompts or logs
- a defined home for model outputs
That's baked into the development process from day one, which tells you these rules are load-bearing and less obvious than they look.
(Worried about staff pasting notes into ChatGPT by hand? That's the mirror image, and we cover PHI in AI prompts separately.)
You can still ship AI in a HIPAA app. It's a handful of steps in the right order, and none of them are complicated once you know what they are.
The consumer/API divide: why ChatGPT and the OpenAI API are different products
Ask a team "which model are you using?" and you'll hear "ChatGPT." Ask what that actually means and the answers scatter. "We use ChatGPT" can point at a half-dozen different products, and they don't share a compliance posture. Conflating them is the single most common way PHI ends up somewhere it shouldn't.
Consumer ChatGPT is never BAA-eligible
It splits like this:
- Never eligible for a BAA: Free, Plus, Pro, and Team.
- Can sign one: the OpenAI API for programmatic use, plus the sales-managed ChatGPT Enterprise and ChatGPT for Healthcare.
ChatGPT for Healthcare is a real, generally available product: a secure workspace built to support HIPAA compliance, with audit logs through its Enterprise Compliance API. The other path, the one most builders actually want, is the API you call from your own code.
Everyone calls it the ChatGPT API. HIPAA-eligible or not comes down to which product you're hitting and whether the BAA is signed. The word "ChatGPT" in the name tells you nothing.
ChatGPT Business is the trap
Business is the self-serve tier between Team and Enterprise, and it looks exactly like a work-ready paid plan. It is one, for everything except PHI. Self-serve Business is not BAA-eligible. Only Enterprise crosses that line. So if your plan says "Business" and you're routing patient data through it, you have a problem you probably don't know about yet.
The same line runs through every vendor
Every major vendor draws it. Anthropic's consumer tiers, Free, Pro, Max, and Team, sit outside any BAA, and a September 2025 opt-in even lets consumer chats train models, with retention running as long as five years. The same split shows up at Google, at AWS, everywhere. Same rule, whatever the brand on the login page.
So learn the shape of it. Consumer surfaces, whatever the vendor calls them, don't sign BAAs. The programmatic path does: your own API keys and a signed BAA behind them. A chat window doesn't count as that path, however enterprise it looks.
What an LLM BAA actually covers, and the line it draws between you and the vendor
Sign an OpenAI BAA and it's tempting to feel done. The signature is real and it matters, but it covers a narrower slice of the problem than most teams assume, and the part it leaves out is the part that breaches you.
What a BAA actually does
A signed business associate agreement (BAA) turns the vendor into your business associate under 45 CFR 164.504(e). That's a legal status with teeth: it puts the vendor on the hook for breach notification, forces its own subcontractors under the same rules, requires it to return or destroy PHI when you walk away, and bars it from training on your data.
If you want the ground-floor version of what a BAA is and does, we cover what is a business associate agreement on its own. The useful part here is where its coverage stops.
The three doors PHI can leave through
Step back to the rule the BAA is satisfying. Under HIPAA, PHI can cross your compliance boundary only three ways:
- To a vendor you've signed a BAA with.
- As a limited data set, under a data use agreement.
- As de-identified data, cleared through Safe Harbor or Expert Determination (45 CFR 164.514).
A programmatic LLM call is door one.
The BAA stops at the vendor's edge
The line that actually matters runs down the middle of your pipeline. The BAA covers the vendor's processing of PHI, and nothing on your side of it.
Your side is longer than most teams expect:
- The PHI you choose to send, plus everything riding alongside it in prompts, schema definitions, and logs
- Where model outputs land, how long they stay, and who can read them
- Your vector store and everything retrieval writes into it
- The observability and analytics tools sitting between your app and the API
- The audit trail that proves all of the above
That's a shared responsibility model, and the piece teams forget most often is the tooling in between.
Observability tools like Datadog and Sentry, and product analytics like Segment and Mixpanel, are business associates in their own right. The moment your error traces or usage events carry PHI, each of them needs its own signed BAA.
It's one of the most common misses we see: the model vendor's BAA signed, and full request payloads flowing into an error tracker that never signed one. The vendor's signature does nothing for that path.
You can be compliant with retention switched on
Teams read "HIPAA-eligible" and hear "nothing is stored." Both major vendors say otherwise, plainly:
- OpenAI's Eyes Off and Safety Retention modes let BAA-eligible endpoints process PHI even while data is retained.
- Anthropic's HIPAA readiness applies broader safeguards like encryption, access controls, and audit logging rather than deleting everything the instant it arrives. Some of its models require 30-day retention and can't be used with ZDR at all.
That misread costs you. Teams rule out prompt caching and hosted retrieval, retention-dependent features they were entitled to use, or they burn effort chasing a ZDR setup they never needed.
OpenAI's HIPAA path: the BAA process, zero data retention, and the healthcare addendum
Out of the box, the OpenAI API is not ready for patient data. It stores inputs and outputs for up to 30 days for abuse monitoring, and staff can review flagged content. None of it trains a model, but 30-day retention of patient data isn't something you can wave through. Everything that changes that is something you have to go and do.
The order matters.
1. Request the BAA and execute the healthcare addendum
Start with sales or write to hipaa@openai.com. What you sign is the OpenAI Business Associate Agreement together with the Healthcare Addendum, which sets out how OpenAI handles PHI as your business associate, what happens to that data when the contract ends, and the obligations you carry for your own healthcare activities.
Approval is case by case, so treat this as a step with a lead time rather than a checkbox. The BAA term starts when you first send PHI, not when the ink dries.
2. Get your organization provisioned
The paperwork alone doesn't flip anything on. OpenAI provisions your organization for Eyes Off or Safety Retention, and only then can BAA-eligible endpoints process PHI even when data is retained. You'll see this called the approved org ID mechanism. Until your org ID is on that list, a signed BAA and a production API key still leave you non-compliant.
3. Choose a retention control
Two options, both approval-gated, and you pick one or the other:
- Modified Abuse Monitoring, which keeps your content out of abuse-monitoring logs across every endpoint while leaving the full platform available.
- Zero Data Retention, which does the same to the logs and also forces store to false on responses and chat/completions.
Either can be set for the whole organization or scoped to a single project, which is what you want when one project touches PHI and the rest don't.
4. Confirm data residency, then decide who holds the keys
US is the default region. Running anywhere else means Modified Abuse Monitoring or ZDR plus a Modified Retention amendment. Data residency endpoints also carry a 10% uplift for models released on or after March 5, 2026.
If your security review raises the question, Enterprise Key Management supports customer-managed keys through:
- AWS KMS
- Google Cloud
- Azure Key Vault
Nothing in OpenAI HIPAA setup happens by default
The model training opt-out is the only thing you get for free, since the API has excluded business data from training since March 2023. The retention window and the permission to send PHI at all both wait for you to go and ask.
Endpoint eligibility, and why store:false is not zero data retention
Two controls get treated as one: the store parameter you set in a request, and zero data retention on your account. They sit at different levels and do different jobs. The gap between them is where teams believe they've switched retention off and haven't.
store:false is a smaller switch than it looks
On /v1/responses and /v1/chat/completions, the store parameter governs exactly one thing: whether OpenAI keeps the response object. Responses defaults to holding it for 30 days as application state. Set store:false and that copy never gets written.
That's the full extent of it. Your prompts and completions still pass through abuse monitoring, still sit in that pipeline for up to 30 days, and can still reach a human reviewer if something trips a flag.
The abuse-monitoring pipeline is what changes at the account level, and OpenAI grants two controls:
- Modified Abuse Monitoring keeps your content out of the logs across every endpoint.
- Zero Data Retention (ZDR) does that and also forces store to false.
Neither is something you toggle in code. Together those two effects mean an eligible endpoint retains nothing, which is where the name comes from.
The overlap is what breeds the confusion. Once org-level ZDR is active, store is treated as false on every request whether you set it or not, so the two produce similar-looking symptoms from very different causes. Only one of them is OpenAI zero data retention, and it isn't the one in your request body.
Statelessness decides which endpoints can carry PHI
Eligible endpoints, stateless inference:
- chat/completions and responses
- embeddings
- audio transcription, translation, and speech
- moderations
- realtime
Not eligible, because they retain application state until you delete it:
- Assistants and Threads
- Vector Stores and Files
- Batch
- Fine-tuning
For patient data specifically, narrow it further. Under the BAA with retention in play, only the chat completions API and responses are Eyes Off and Safety Retention eligible. Those two are your PHI path, once your org is provisioned.
Everything in the second group is storage you own, and turning on ZDR doesn't rescue it. Non-eligible endpoints can still hold application state with ZDR enabled. It sits there until something deletes it, and that something is you.
One edge case for deployments outside the US: non-US regions can't set store:true at all.
The other compliant paths: Azure OpenAI, Anthropic Claude, Google Vertex AI, AWS Bedrock
OpenAI isn't the only path, and for plenty of teams it isn't the obvious one. All four major alternatives sign a BAA, each through a different mechanism, with different defaults and a different thing to watch for.
They can all be made compliant. So the useful question is which path fits the stack you already run.
Azure OpenAI
HIPAA coverage arrives through Microsoft's Product Terms and the Online Services Data Protection Addendum, so there's no separate document to chase.
Retention behaves much like OpenAI's:
- Standard pay-as-you-go holds data for 30 days.
- Clearing it means applying to the Modified Abuse Monitoring program.
- That program is approval-gated, same as OpenAI's.
- ContentLogging=false is visible in the portal.
That last one is what Azure gives you and OpenAI doesn't: a way to confirm the setting took effect instead of trusting that it did. Region pinning is available if your data has to stay somewhere specific.
For teams already invested in Microsoft's cloud, Azure OpenAI HIPAA setup is mostly a matter of confirming what procurement signed years ago.
Anthropic Claude
The BAA covers the first-party Claude API. HIPAA readiness then has to be switched on in the Console, and on Claude Enterprise an admin enables HIPAA mode separately.
Retention is the friendliest default of the group, since the API doesn't hold conversation content and backend copies clear in 30 days.
The catch with an Anthropic BAA is scope. Coverage lands on the Messages API and a named set of features. Six surfaces sit outside it:
- Batch
- Files
- Skills API
- Code Execution
- Computer Use
- Web Fetch
On a HIPAA-ready API org those surfaces aren't accessible at all, so the request fails rather than quietly proceeding, which is the behavior you want.
Google Vertex AI / Gemini
Google Vertex AI / Gemini spans two surfaces, and only one of them counts. Vertex AI on Google Cloud is a Covered Service under the Google Cloud BAA. Consumer Gemini and AI Studio are not, whatever the model underneath.
Accept the BAA, turn on the project-level HIPAA flag, and inference runs inside your own GCP project and region under your own IAM policies. That's a meaningful difference if your security team wants patient data to never leave infrastructure they control.
AWS Bedrock
AWS Bedrock joined the HIPAA Eligible Services Reference in 2024, with AgentCore added on February 10, 2026. The AWS BAA is self-serve through AWS Artifact, so there's no sales conversation to schedule.
Two things work in your favor:
- Bedrock doesn't store your prompts or train on them.
- Private VPC endpoints keep traffic off the public internet.
The wrinkle is that Bedrock hosts other companies' models, each under its own acceptable-use policy. Claude running on Bedrock is covered by your AWS BAA, not Anthropic's, which catches teams who assume the model vendor's agreement follows the model.
How the paths compare
Read down the table and the consumer/API split holds at every one of them. SOC 2 doesn't separate them either, since they all have a report.
The caveat that outlasts the choice: HIPAA-eligible has never meant HIPAA-compliant. Whichever path you pick, what your architecture does with the data afterward is still yours.
Architecture patterns that keep PHI safe in LLM features
The same pipeline works for every AI feature you ship. Build a HIPAA compliant LLM integration once and the compliance question stops being something you relitigate per feature. Teams still get this wrong with the sequence right in front of them.
The PHI-safe pipeline, stage by stage
Seven stages. Each one narrows what the next can expose.
- Start in your own system. Identify which fields are PHI before anything leaves, including free-text notes where identifiers hide.
- Redact or de-identify on the way out. Send the clinical text the model needs, not the name and MRN attached to it.
- Call an eligible endpoint on a provisioned org. Chat/completions or responses, with your retention control approved and Eyes Off or Safety Retention switched on for your org ID.
- Guard the call itself. No PHI in system prompts, JSON schema definitions, property names, or anything you log.
- Retrieve from a store you control. The embeddings endpoint is eligible, but the vector database holding those embeddings is yours to encrypt and manage.
- Control what comes back. Decide what gets displayed, what gets stored, and who can see it.
- Write the audit trail. Scalar metadata only, kept for 6 years.
What redaction actually buys you
Stripping patient data before the call reduces what's exposed if anything downstream fails. Worth doing. It buys you a second layer, and teams keep mistaking it for permission to skip the first.
Automated PHI redaction rarely clears the legal bar on its own. NLP de-identification misses identifiers buried in free text, and one false negative means patient data left your boundary unprotected.
The bar itself is specific. HIPAA recognizes two methods:
- Safe Harbor, which means removing all 18 identifiers with no remaining knowledge that the data could identify someone
- Expert Determination, where a qualified expert documents that re-identification risk is very small
Clear either and the data stops being PHI entirely. Miss by one identifier and it never stopped being PHI at all.
So keep the BAA and let de-identification work underneath it.
Synthetic data has a real place in this, just not in production. Your development and staging environments shouldn't hold live patient records, and generated stand-ins let you build and test without that exposure.
Encryption sits under all of it: TLS for encryption in transit, encrypted storage at rest, and customer-managed keys when your security review asks for them.
This is the pipeline behind an AI medical scribe app, which is about as PHI-dense as a feature gets.
The storage traps: fine-tuning and RAG
Two stages quietly turn into storage, and both catch people.
Fine-tuning is the first
Submit patient data to tune a model and OpenAI keeps those files until you delete them. That endpoint isn't ZDR-eligible either. Anything you upload there is PHI storage you now own and have to manage on a retention schedule, the same as a database.
Retrieval is the second
RAG (retrieval-augmented generation) is how most teams give a model access to patient history, and the eligibility splits mid-pipeline. The embeddings endpoint is ZDR-eligible, so generating vectors is fine. The store holding them is your problem.
OpenAI's hosted vector store retains until deletion, so either run a compliant encrypted vector database yourself or accept that retention under your BAA with real deletion discipline around it.
Retrieval-heavy features like AI clinical decision support live or die on getting that store right.
The agentic boundary
Agentic features reach outside your architecture by design, which is exactly the risk. With OpenAI, live-internet web search isn't HIPAA-eligible or BAA-covered, though cache-only mode can be.
Anthropic covers Web Search but not Web Fetch, so each vendor draws this line in a different place. Remote MCP servers are the one point they agree on: data sent there falls under that third party's retention terms, not your vendor's agreement.
Keep patient data away from both, or constrain them before they get near it. Same applies to AI agents in healthcare generally: an agent with tool access is only as contained as the tools you gave it.
Log the access, not the data
Every PHI read and write needs an audit trail, and the trail has to stay clean itself. Log scalar metadata: who touched what record, when, and which action. Never the values. Keep that documentation for 6 years, per 45 CFR 164.530(j).
The same discipline covers places that don't look like logs. Filenames go out with the request the same way system prompts and schema definitions do, and compiled schemas get cached separately without the same protections around them.
Common mistakes that break compliance even with a signed BAA
Every failure below sits on your side of the line. The vendor's signature alone does nothing to stop any of them.
Running a consumer or self-serve tier in production
ChatGPT Free, Plus, Pro, Team, and self-serve Business. Claude Free, Pro, Max, and Team. Consumer Gemini and AI Studio.
Fix: move to the API or a sales-managed enterprise tier under a BAA.
Routing PHI to an endpoint that can't carry it
On OpenAI that's Assistants, Threads, Vector Stores, Files, Batch, and Fine-tuning. On Anthropic it's Batch, Files, Skills API, Code Execution, Computer Use, and Web Fetch.
Fix: keep patient data on the eligible inference endpoints.
Assuming the BAA switched retention off
It didn't, and the 30-day abuse-monitoring window is still running behind your feature.
Fix: get provisioned for ZDR or Modified Abuse Monitoring explicitly.
Piping PHI into observability and analytics
Datadog, Sentry, Segment, and Mixpanel receive whatever your instrumentation hands them.
Fix: sign BAAs with each, or scrub patient data before telemetry leaves the app.
Leaking PHI outside the message body
System prompts, JSON schema definitions, property names, and filenames ride along with every request, and prompt logging quietly accumulates the rest.
Fix: apply the minimum necessary standard to what you send, and log scalar metadata only.
Forgetting that fine-tuning stores and agents leave
Tuning files sit on the vendor's side until you delete them, while live web search and autonomous agents can move data outside your vendor's covered surface.
Fix: manage tuning data on a retention schedule and constrain what agentic tools can reach.
Treating HIPAA-eligible as HIPAA-compliant
Eligibility is a vendor property. Compliance is a property of your system, and that's the one OCR asks about.
Fix: audit your own setup, because that's where the answer lives.
Whether you're a covered entity or a business associate serving one, every item above is yours. The same failure modes show up anywhere speed outruns review, which is the whole problem with vibe coding a healthcare app that touches real patient data.
How Specode can help with the compliance layer under your LLM features
Everything above is doable by hand. Sign the vendor BAA, get your org provisioned, pick your endpoints, build the redaction layer, wire the audit trail, document all of it. That's real work, and none of it is the feature your users came for.
Specode starts you further along the sequence. The platform is HIPAA-compliant by default, so auth, data access patterns, and audit-friendly workflows exist before you write your first prompt. Backend and front-end hosting comes with a BAA included, which takes one negotiation off your list.
The model vendor agreement is still yours to sign. That part doesn't transfer, and everything above is how to do it. What Specode covers is the infrastructure underneath:
- Audit logging planned and implemented across your PHI surfaces, with scalar-only metadata that never carries patient values
- An automated HIPAA scan running 37 checks against your codebase, separating what has to be fixed from what's worth hardening
- On-demand penetration testing when procurement asks for it
- A security and HIPAA review by our team before you go live
You own the code outright. Export it whenever, deploy it wherever, no lock-in.
If you're wiring a HIPAA compliant AI API into a healthcare product, the layer underneath it is already built. See how Specode handles it.
Frequently asked questions
The API, plus the sales-managed ChatGPT Enterprise and ChatGPT for Healthcare, can be, once you sign a BAA and stay on eligible endpoints. Consumer ChatGPT never is.
Not through the consumer app. Through the API or ChatGPT Enterprise, yes, once you've got a signed BAA, a provisioned org, and eligible endpoints.
Yes, for the first-party Claude API and Claude Enterprise. You execute the BAA in the Console, and on Enterprise an admin switches on HIPAA mode separately. Consumer tiers are excluded.
ZDR keeps your prompts and responses out of abuse-monitoring logs, replacing the default 30-day window, and forces store to false. Nothing survives the call on an eligible endpoint, hence the name. Set store:false yourself and you get none of the log protection.
If de-identification demonstrably meets Safe Harbor or Expert Determination, the data isn't PHI and needs no BAA. Automated redaction rarely clears that bar, so most teams keep it.
