is ChatGPT HIPAA compliant? what a practice can put in it
no, not by default. HIPAA lets a practice hand patient information to a vendor like OpenAI only under a business associate agreement. OpenAI offers one for its API, for sales-managed ChatGPT Enterprise and Edu accounts and for eligible clinicians, not for ChatGPT Business, and says a BAA alone doesn't make an application HIPAA compliant.
practice administrators keep asking the wrong version of this question. they ask whether ChatGPT is HIPAA compliant, as if it's a yes or no about the product. the real question is narrower and more useful: are your staff pasting protected health information into an account that has a signed business associate agreement, zero data retention, and a deterministic check on what goes in and out. for the Free, Plus and Business plans sitting in a browser tab, the answer to that real question is almost always no. signing a BAA with OpenAI doesn't change that by itself either, because a BAA governs the vendor's obligations, not what your front desk does at 4pm when a patient calls about a billing error.
is there a version of ChatGPT that is HIPAA compliant?
there are versions OpenAI will sign a BAA for. none is compliant on its own. consumer ChatGPT, the kind anyone can sign up for with an email address, has no business associate agreement attached to it by default. HHS describes the BAA as the "satisfactory assurances, in the form of a contract or other written arrangement" a covered entity needs before it discloses PHI to a vendor. no BAA means no covered entity should be putting PHI anywhere near it, full stop. OpenAI's help center lists a BAA for API organizations, for sales-managed ChatGPT Enterprise and Edu accounts, and a separate flow for eligible individual clinicians, and it says it does not offer one for ChatGPT Business. on the covered tiers, inputs can also be set to zero data retention, meaning the conversation isn't used to train future models and isn't kept around past the processing window. that's the only configuration where the question of compliance even starts to be answerable.
but a signed BAA and a zero-retention setting are necessary, not sufficient. OpenAI says so itself: a BAA and HIPAA support "do not, by themselves, make your application HIPAA compliant." a BAA tells you the vendor will handle PHI responsibly if PHI reaches them. it doesn't tell you that your intake coordinator won't paste an entire patient history into a chat window to get a quick summary, on a personal plus account, because the enterprise version takes longer to log into. the gap between what's contractually permitted and what actually happens on a Tuesday afternoon is where most practices get exposed. the tool being theoretically compliant doesn't mean the workflow around it is.
what can a practice safely put into ChatGPT?
there's a wide lane of work that never touches PHI and doesn't need to wait for a legal review of your AI policy. staff scheduling templates. generic patient education handouts that don't reference a specific patient. policy drafting, like updating a no-show policy or a consent form's language. summarizing a clinical protocol or a published guideline, where the input is the guideline itself, not a chart. drafting a job posting, a vendor email, an internal memo about parking.
none of that is a healthcare operations problem. it's a word processing problem that happens to involve a healthcare business. the mistake i see most often is a practice treating every use of an AI tool as equally risky, which leads to either blanket bans that frustrate staff into using the tool on their phones unsupervised, or blanket permission that assumes good judgment will hold under deadline pressure. neither is a system. a system draws the line explicitly, before anyone is in the middle of a task deciding where it is.
is it safe to put medical records into ChatGPT?
not unless the account is covered by a BAA, or the records are properly de-identified first, and de-identification is harder than it looks. HIPAA lists eighteen identifiers that make information protected health information when tied to health data: name, dates tied to an individual, phone numbers, email addresses, medical record numbers, account numbers, device identifiers, photos, and more down to ZIP code in some cases. the instinct a lot of practices have is to let a staff member manually strip the obvious ones, a name here, a date there, before pasting something into a chat window.
manual redaction fails in a specific, repeatable way: humans are good at catching the identifier they're looking for and bad at catching the ones they weren't thinking about. someone redacts the patient's name and leaves the date of birth and the referring physician's name in the same paragraph, and now you have a re-identifiable record through two identifiers instead of one, done by someone who believed they'd made it safe. de-identification under HIPAA's safe harbor method is a specific, complete removal of all eighteen categories, not a vibe-based scrub. HHS's guidance says the identifiers have to come out "of the individual or of relatives, employers, or household members," and the practice must also have no actual knowledge that what's left could identify the patient. doing that scrub by hand, under time pressure, at scale, is where good intentions turn into a reportable incident.
the model reads and extracts, deterministic code strips and routes
this is the architectural choice that actually matters, and it's the same one i use for any regulated workflow i build, prior authorization included, not just healthcare ones. the language model should never be the thing deciding whether a piece of text is safe to send forward. a model is probabilistic. it can miss an identifier the same way a tired staffer can. what should never miss is a deterministic function: code that runs the same check the same way every time, flags every one of the eighteen categories by pattern, and either strips it before the text reaches any model endpoint or routes the whole document to a human instead of guessing.
concretely, that looks like this: incoming text is scanned by rule-based logic first, PHI is pulled and replaced with placeholders, and only the scrubbed version goes to the model, whether that model is a consumer endpoint or an enterprise one. the model can read the de-identified version, extract structure, draft a summary. it never sees the original. if the scrubber isn't confident a field is clean, the document doesn't go through at all, it goes to a person. that's the same principle as a zero-data-retention API setting applied one layer earlier: don't trust the probabilistic step with the decision that has to be right every time.
building an audit trail inside your own cloud infrastructure
the reason this needs to live in the practice's own infrastructure, not inside a vendor's dashboard, is that the whole point is being able to answer a question six months from now: what PHI was in this request, what was stripped, who approved the output, when. a third-party chat interface doesn't give you that. your own logging layer, sitting in your own cloud account, does.
that means every document that enters the pipeline gets a log entry before de-identification, a log entry after, and a log entry for whatever left to reach a model. if a redaction check fails, that failure is itself logged, not silently retried. the practice can hand an auditor a line-by-line record instead of a vendor's word that things were probably fine. it also means if a practice ever wants to switch which model sits behind the pipeline, that's a configuration change, not a migration, because the PHI handling layer was never the vendor's to begin with.
most practices don't have this today, because most practices bought a chat tool, not a pipeline. the gap between is ChatGPT HIPAA compliant and is this specific workflow HIPAA compliant is exactly the gap a workflow audit is built to close. the Workflow Audit is a two-week engagement, $2,500, credited toward a build if you move forward, and it exists to look at where PHI actually enters your systems today, before a model ever touches it, and tell you plainly what's exposed.
the fix here isn't picking the right AI product. it's deciding, in writing, where PHI stops before it reaches any model, and building code that enforces that decision instead of hoping staff remember it under pressure.