OpenAI API BAA Adds Self-Service HIPAA Setup
Eligible API organization admins can accept OpenAI's standard BAA in settings. Review the enrollment steps, retention conditions, and endpoint and tool coverage before using protected health information.
OpenAI API BAA enrollment now has a self-service route for eligible organizations. OpenAI’s October 5 API changelog says authorized organization admins can accept the standard Business Associate Agreement and enable HIPAA support in organization settings. The update changes the enrollment workflow; endpoint coverage and data configuration still need separate review.
What changed for OpenAI API BAA enrollment
The new flow puts standard agreement acceptance inside the API Platform, under the organization’s General settings. This is useful for the administrator arranging access and the engineer preparing an integration: they can work from the same organization identity rather than treating contract acceptance as an unrelated onboarding task. The official API changelog dates the change to October 5, 2026.
This article covers that dated setup change. For general request setup and model selection, use our API guide; those choices do not establish a healthcare deployment’s eligibility.
Who can use self-service enrollment?
According to the BAA enrollment FAQ, an enterprise contract is unnecessary for API enrollment, but an organization needs an established API usage history. OpenAI publishes no numeric threshold there. A “Not eligible yet” message means the organization does not qualify for self-service. Acceptance requires an administrator authorized to manage settings and sign for the organization.
The practical decision is which organization will own the application. Before starting, our recommendation is to ask the integration owner to identify the intended organization and project, then have the authorized administrator review that choice. Keep a sandbox organization and a production organization distinct in your handoff notes. This avoids accepting an agreement for one organization while preparing credentials for another.
How to enable HIPAA support in the API Platform
Select the intended organization, open Settings, then Organization and General. In the HIPAA section, choose Enable, download and review the agreement, and check the covered services. Complete the confirmations, verify the organization name and ID, then select “Agree and enable.” A completed setup displays “Active.” Once enabled, HIPAA support cannot be switched off in these settings. Custom agreements remain available by contacting OpenAI; they are not downloadable through the self-service agreement viewer. Acceptance alone does not make an application HIPAA compliant.
For an implementation handoff, record the selected organization ID, agreement-review owner, and completion status without including patient data. A useful status note names the action still needed, such as agreement review or project-configuration review. Avoid a single ambiguous label such as “healthcare ready,” which conceals whether the contract and technical checks are both complete.
Which endpoints and clients are covered?
OpenAI’s eligible-products reference makes API eligibility conditional on Modified Retention provisioning, unless OpenAI specifies otherwise. With that provisioning and an executed BAA, listed endpoints can process protected health information, even when data is retained. The list includes Responses and Chat Completions, alongside several file, audio, image, and other endpoints. It is not a blanket statement about every API capability.
Codex Local using an API key has a related boundary: OpenAI-processed data is covered only when the BAA includes API services with Modified Retention. Local execution and connected third-party services are outside OpenAI’s BAA coverage. The reference separately lists cloud Codex as outside its covered ChatGPT functionality. Do not equate a local client’s authentication method with universal feature coverage.
For related product context, our ChatGPT Health summaries article covers a different workflow. This update concerns API organization enrollment, not a new ChatGPT plan or a model-specific approval.
Retention and web search need their own checks
The API data-controls guide distinguishes abuse-monitoring logs from application state. Modified Abuse Monitoring and Zero Data Retention require approval; project settings can inherit an organization’s controls or explicitly select different behavior. Check the actual project’s configuration rather than inferring it from the organization’s agreement status.
Live-internet web search is not HIPAA eligible under a BAA. Offline search using external_web_access: false can be eligible only with the Responses API’s web_search tool and a key belonging to a ZDR-enabled project inside a ZDR organization. The preview tool ignores that parameter and behaves as though live access is enabled. A disabled-looking option in application code is therefore insufficient without checking the tool variant and project.
The guide also treats remote MCP servers as third-party services with their own retention policies. Include those destinations in a data-flow review, not just the request sent to OpenAI. Application-state retention and exceptions should be assessed for the features actually enabled.
Example: a configuration handoff without patient data
The following is our editorial planning example, not an executed integration or an OpenAI compliance checklist. Consider a team preparing a document-summary prototype. Start with entirely synthetic text, and create a short inventory before deciding whether real clinical material belongs in the workflow.
Give each inventory row an owner and a specific question. The organization row asks which legal entity and organization ID the administrator reviewed. The project row asks which project owns the credential used by the application. The endpoint row names the intended request path. A tool row records whether the request can search, call a connector, or contact another service. A storage row identifies where the team’s own inputs, outputs, and troubleshooting records will go.
For the prototype, write down two test cases: a summary request with no external tool, and a request that attempts to use the planned search feature. The purpose is to compare the intended configuration with the application’s actual behavior using synthetic material. Record the observed endpoint and tool variant, not only the friendly feature name shown in the interface. If either differs from the inventory, return the configuration to its owner for review before proceeding.
Close the handoff with unresolved items rather than a promise of compliance. For example, an engineer might confirm the request path while an administrator is still checking the project’s retention setting. Keep those as separate statuses. This makes the October 5 enrollment update actionable: contract acceptance has a clearer route, while the implementation team retains a concrete record of the configuration questions it still needs to resolve.