You finish a long visit, open ChatGPT, and start typing the patient's history to draft a referral letter faster. Stop. Standard ChatGPT is not HIPAA compliant, and pasting protected health information into it is itself a HIPAA violation. As of June 2026, OpenAI does not sign a Business Associate Agreement for the Free, Plus, Pro, or self-serve Team and Business tiers, so none of those accounts may touch PHI.
Here is what most articles on this question miss. They stop at "get a BAA and you're fine," as if the signature is the whole story. A BAA is a contract, not a wall. Even with one signed, the patient note still leaves your building and runs on someone else's servers, where it can be processed, logged, and sometimes retained under terms you do not control day to day. That gap between a legal promise and a physical boundary is the part you need to understand before you decide where a clinical note can safely go.
What HIPAA actually requires before any vendor touches PHI
Any vendor that handles protected health information on a covered entity's behalf must sign a Business Associate Agreement first. That is the rule, not a best practice. The BAA is the written contract that obligates the vendor to safeguard PHI, limit how it gets used, and report breaches. Hand PHI to a service with no signed BAA in place and you have already breached HIPAA, no matter how the service behaves afterward.
PHI is broader than people assume. It is any individually identifiable health information a covered entity holds or transmits: a name tied to a diagnosis, a date of service, a medical record number, even a phone number paired with a condition. It does not have to be a formal chart entry. A quick note pasted to draft a letter counts just as much. The moment that combination lands in a chat box on a non-covered service, you are in HIPAA territory and probably already over the line.
The stakes are not abstract. HIPAA penalties run in four tiers. After the inflation adjustment that took effect on January 28, 2026, the most serious tier, willful neglect left uncorrected, reaches up to $2,190,294 per year for a single category of violation. The Office for Civil Rights settles many cases with corrective action plans rather than maximum fines, but the exposure is real. A clinician's own paste into a consumer chatbot is exactly the kind of unauthorized disclosure that opens that door.
Which OpenAI tiers will and will not sign a BAA
OpenAI will sign a BAA, but only on specific paid paths, and never on the consumer ones. As of June 2026, a BAA is available for API customers, for sales-managed ChatGPT Enterprise and Edu accounts, and through the dedicated ChatGPT for Healthcare offering. It is not available for Free, Plus, Pro, or self-serve Team and Business. For the API, OpenAI's documented requirement is that you request the agreement at [email protected] and use endpoints configured for zero data retention.
OpenAI launched ChatGPT for Healthcare in January 2026 as an enterprise product for hospitals and clinicians, then added a free ChatGPT for Clinicians path for verified US clinicians in April 2026. Here is the trap nobody puts in the headline: that free clinician tool is built for tasks that do not require PHI, and HIPAA support is only optional, through a separate BAA for eligible accounts. The word "clinician" on the product does not mean the patient note is covered. OpenAI itself states these products are not HIPAA compliant out of the box; they enable compliant use only with the right configuration, access controls, and governance.
The consumer chat you already use is covered by a BAA roughly never. A BAA lives on the API and on sales-managed enterprise paths, not on the Plus subscription open in your browser.
The catch a BAA does not fix: a contract is not architecture
A signed BAA changes who is liable, not where your data goes. Even with the agreement in place, the patient note still travels to OpenAI's servers for inference, and depending on the contract terms it can sit there for some window before deletion. A BAA is a contractual control: a promise, plus legal liability if that promise breaks. It is not an architectural control, which would mean the data never left your control in the first place. Those are different kinds of protection, and conflating them is the mistake.
Think of it like handing a sealed envelope to a courier. A good contract says the courier will not open it and will pay you if they do. Architecture is never handing over the envelope at all. Both have their place, but only one removes the question of trust entirely. With a chatbot, the envelope is open by design, because the model has to read the contents to answer.
Why does that distinction bite in practice? Because events outside your contract can override it. In the New York Times copyright case against OpenAI, a federal court in May 2025 ordered OpenAI to preserve output logs that would otherwise have been deleted, overriding normal deletion for Free, Plus, Pro, Team, and API usage that lacked a zero-data-retention agreement. That broad order was narrowed in late September 2025, and OpenAI resumed standard deletion afterward. Treat it as a demonstrated risk, not today's policy: data sitting on a third party's servers can be frozen by a court your BAA never anticipated.
Enterprise tiers and zero-data-retention API endpoints were excluded from that preservation order. If you are pursuing a compliant ChatGPT path, the configuration details, not just the signature, are what keep PHI out of a future discovery sample.
Contractual control versus architectural control, side by side
| Dimension | BAA (contractual) | Data stays under your control (architectural) |
|---|---|---|
| What it is | A promise plus liability if PHI is mishandled | PHI never leaves a system you operate |
| Where PHI goes | To the vendor's servers for processing | Stays in your environment or de-identified before exit |
| Failure mode | Breach happens, then you have recourse | Exposure is prevented, not remediated |
| Exposure to outside orders | Vendor data can be subject to court preservation or subpoena | Nothing for an outside party to compel from a vendor |
| HIPAA status for PHI | Required and sufficient with proper config | Not a substitute for a BAA when PHI is involved |
Read the bottom row twice. Keeping data under your own control is a strong privacy posture, but on its own it does not make a tool HIPAA-eligible for PHI. The covered-entity rule is still the rule. The two columns solve different problems, and a serious clinical workflow often needs both: a BAA for the compliant path, and the discipline to never push raw PHI anywhere it does not belong.
The compliant moves: de-identify or use a covered path
You have two clean options. Use a BAA-covered, properly configured path for anything that contains PHI, or strip the PHI first. HIPAA's Safe Harbor method de-identifies a record by removing 18 categories of identifiers and confirming you have no actual knowledge that what remains could re-identify the person. Those categories include names, all geographic detail smaller than a state, dates more specific than a year that relate to the individual, phone and fax numbers, email addresses, Social Security and medical record numbers, account and license numbers, and full-face photos.
Safe Harbor has a trap the checklist hides. Removing the 18 identifiers is necessary but not sufficient. You also have to meet the "actual knowledge" condition: if you know the remaining details could still single someone out, the record is not de-identified. HHS gives a blunt example, a record listing the patient's occupation as "former president of the State University" fails even with the name gone, because that one field identifies the person. A rare diagnosis in a tiny clinic does the same. When in doubt, treat it as PHI and route it through the covered path.
A quick decision flow before you hit enter
About to paste something into an AI tool? Run three questions in order. They take seconds and keep you on the right side of the rule.
- Does this text identify a specific patient, alone or in combination with other details? If yes, it is PHI and the consumer chatbot is off the table.
- Do I have a signed BAA on a properly configured path for this exact tool? If no, do not send PHI to it, no matter how routine the task feels.
- Can I do the job with the PHI fully removed under Safe Harbor, or with my own non-PHI reference material instead? If yes, that is usually the fastest compliant route.
Two practical notes. Free-text dictation is where PHI slips in by accident, so be deliberate about what you transcribe into a prompt. And browser extensions or third-party wrappers that route prompts through ChatGPT do not inherit a BAA from OpenAI; the BAA has to cover the actual service that receives the data. If you cannot name the covered-entity-to-business-associate chain for a given tool, assume it is not covered.
Where a private store fits, and where it does not
Plenty of what a clinician keeps in a chatbot is not PHI at all: drug interaction notes, guideline summaries, board-study material, templated language you reuse, the way you like a referral letter structured, your own reference snippets. None of that identifies a patient. For that material, a private store you control beats pasting it into a public model that may use general consumer inputs to improve its systems. MemX is built private by architecture: per-user isolation, encryption at rest, and your content is not used to train models. It gives ChatGPT, Claude, or Gemini persistent memory of your reference notes, so you stop re-pasting the same context every session, without dumping that material into a shared consumer surface.
Be precise about the line. MemX is not a HIPAA-covered system, it is not a BAA vendor, and it is not a place for protected health information. It does not replace a compliant path. For actual PHI, the only acceptable route is a BAA-covered, properly configured service. The honest pitch is narrow: keep your own non-PHI reference material out of a public chatbot and under your control, and use a compliant path for anything that identifies a patient.
Non-PHI reference notes: a private store you own. Patient PHI: a BAA-covered path only. Do not let the convenience of one bleed into the requirements of the other.
Frequently asked questions
01Is ChatGPT HIPAA compliant?
No. As of June 2026, standard ChatGPT (Free, Plus, Pro, and self-serve Team or Business) is not HIPAA compliant, because OpenAI does not sign a BAA for those tiers. Pasting protected health information into them is a HIPAA violation.
02Does OpenAI sign a BAA?
Yes, but only on specific paths: the API with zero-data-retention endpoints, sales-managed ChatGPT Enterprise and Edu accounts, and the ChatGPT for Healthcare offering. API customers request one at [email protected]. Consumer tiers are never covered.
03If I sign a BAA, is my PHI fully protected?
A BAA makes the use lawful and gives you recourse, but PHI still travels to OpenAI's servers for processing. A BAA is a contractual control, not an architectural one. It assigns liability; it does not keep the data inside your own systems.
04Can I use ChatGPT if I remove patient names first?
Removing names is not enough. HIPAA Safe Harbor requires removing all 18 identifier categories and confirming the remaining data cannot re-identify the person. Done correctly, de-identified data is no longer PHI and falls outside HIPAA.
05Is MemX HIPAA compliant for storing patient notes?
No. MemX is a private-by-architecture personal store for your own non-PHI reference material, not a HIPAA-covered system or BAA vendor. Do not put protected health information in it. For PHI, use a BAA-covered, properly configured path instead.
The takeaway
Standard ChatGPT is not HIPAA compliant, and as of June 2026 a BAA only exists on the API and sales-managed enterprise paths, never on the consumer tiers. Even where a BAA is in place, it shifts liability rather than keeping the data inside your walls, which is why a court order once froze logs that were supposed to be deleted. For PHI, use a BAA-covered, correctly configured path or de-identify with Safe Harbor first. For your own reference material, keep it private and under your control. Do not blur the two.
