ChatGPT Healthcare Use Cases

What are ChatGPT healthcare use cases?

ChatGPT healthcare use cases are specific jobs an OpenAI model drafts for a person to review, such as a patient handout, an inbox reply or a visit-note draft. Jobs with no PHI can run in any tier the organization approves. Jobs with PHI need an OpenAI product covered by a signed business associate agreement, never consumer ChatGPT.

Which OpenAI products can handle PHI?

Only OpenAI products covered by a business associate agreement can handle PHI for a covered entity. OpenAI publishes which products are eligible, and the list is narrower than the full product line.

• API: OpenAI's help center says it signs business associate agreements for API services that are eligible for zero data retention, and the healthcare addendum ties coverage to those configured services.
• Workspaces: OpenAI offers business associate agreements for ChatGPT Enterprise or Edu through its sales team, and consumer ChatGPT and ChatGPT Business are not covered.
• Healthcare offering: OpenAI launched OpenAI for Healthcare on 8 January 2026, with ChatGPT for Healthcare as a workspace that eligible customers can use under a business associate agreement.
• Feature scope: OpenAI notes that endpoints or features outside its eligible list can still store data even when zero data retention is enabled, so each endpoint in a design has to be checked against that list.
• Contract basis: Under 45 CFR 164.502(e) and 164.504(e), a covered entity may disclose PHI to a business associate only under a written agreement, which is why the product tier decides what staff may paste.

A signed agreement covers the vendor's side. The covered entity still owns access control, workforce policy, minimum necessary limits and audit review for its own users.

Use cases that need no PHI at all

Several useful jobs need no patient data, and these can start without a business associate agreement as long as staff keep identifiers out. They are the safest place to build habits and review routines.

• Patient education drafts: General handouts on a condition, a procedure or medication use, reviewed by a clinician before release.
• Policy and protocol drafts: First drafts of internal procedures, which a compliance or clinical owner edits.
• Training material: Case scenarios written from scratch for staff training, with no real patient details.
• Plain-language rewrites: Simplifying consent forms or billing explanations for reading level, checked by the form owner.
• Engineering help: Writing or reviewing interface code, FHIR queries or test data, using synthetic records only.
• De-identified summaries: Text that meets the HIPAA de-identification standard in 45 CFR 164.514(b), either by Safe Harbor removal of the listed identifiers or by expert determination.

Which PHI use cases are worth piloting?

PHI use cases are worth piloting when a person already reviews the output and the error is caught before it reaches the patient. Each one below runs only in a covered OpenAI product or API configuration.

• Inbox reply drafts: The model drafts a reply to a portal message, and the nurse or clinician edits and sends it.
• Visit-note drafts: The model turns a transcript or dictation into a note in the practice template, and the clinician signs.
• Chart summaries: The model condenses outside records before a visit, with links back to the source documents.
• Prior authorization letters: The model drafts the medical necessity narrative from chart facts, and staff check each fact before submission.
• Coding suggestions: The model proposes codes from the signed note, and a coder accepts or rejects each one.
• Discharge instruction drafts: The model writes instructions at a set reading level, and the discharging clinician reviews them.

Each pilot needs a fixed evaluation set of past cases with reviewed answers. Re-score it whenever the model version or prompt changes, because output can shift even when the job stays the same.

How a covered API path is set up

• 1. Contract first: Sign OpenAI's business associate agreement and healthcare addendum, and confirm in writing which API organization and endpoints it covers.
• 2. Configure retention: Enable zero data retention on the covered organization, and keep a record of which endpoints the application calls.
• 3. Put a service in front: Route every call through a backend service the organization owns, so no client device holds an API key and every request can be logged.
• 4. Trim the prompt: Send only the fields the job needs, and strip identifiers the model does not use, such as phone numbers or member IDs.
• 5. Store outputs locally: Keep drafts, reviewer actions and model versions in the organization's own database under its existing safeguards.
• 6. Block the rest: Use network and identity controls so staff cannot reach uncovered tiers from managed devices for PHI work, and publish the policy that says so.

Where does RPA fit next to a language model?

RPA moves structured data between screens, and a language model handles unstructured text, so some revenue cycle jobs need both. The bot pulls a denial letter from a payer portal, the model drafts the appeal, and a biller reviews before the bot submits.

• Use RPA alone: For fixed, rule-based steps such as copying eligibility results or downloading remittance files, where no judgment is needed.
• Use a model alone: For reading or writing free text, such as summarizing a letter or drafting a reply, when an API path exists.
• Use both: When a job spans a screen with no API and a text step, such as appeals or referral packets.
• Same controls: A bot that sends PHI to a model is part of the same data path, so the model host still needs a business associate agreement and the output still needs a reviewer.

The benefit of pairing RPA with a model is coverage: the bot reaches systems that have no API, and the model handles the letters and notes a bot cannot read. The cost is fragility, because a portal layout change can break the bot, so each bot needs monitoring and an owner who fixes it.

Patient-facing chatbots need tighter limits

A chatbot that talks to patients carries more risk than a staff tool, because no clinician sits between the output and the reader. Healthcare chatbot use cases work best when the scope is narrow and the handoff is fast.

• Narrow scope: Answer questions about hours, preparation steps, billing and how to use the portal, using approved content only.
• No diagnosis: Do not let the bot interpret symptoms or suggest treatment. FDA's CDS guidance treats patient-facing recommendation tools as outside its non-device carve-out, though some may fall under the wellness or enforcement discretion policies.
• Crisis handoff: Detect urgent or self-harm language and route to a human or emergency instructions immediately.
• Clear labeling: Tell patients they are talking to an automated system, and check state laws on AI disclosure in patient communications.
• Logging: Store conversations under the same safeguards as other ePHI, and review samples for wrong or unsafe answers.

Which privacy rule applies depends on who runs the bot. A chatbot a provider offers to its own patients sits under HIPAA. A direct-to-consumer health app that is neither a covered entity nor a business associate falls under the FTC Health Breach Notification Rule (16 CFR Part 318) instead, which sets its own breach notice duties.

A decision list for any proposed use case

Run each new request through these questions before anyone opens a chat window. A no on any of the first three ends the request until it is fixed.

• PHI check: Will the prompt, an attached file or the output contain PHI? If yes, only a covered product or API configuration may be used.
• Product check: Is the planned OpenAI product on the eligible list, and is the business associate agreement signed?
• Reviewer check: Who accepts, edits or rejects each output, and do they have time for it?
• Clinical check: Does the output inform a diagnosis or treatment? If yes, read the intended use against FDA's CDS criteria.
• Audience check: Is the output shown to patients without review? If yes, apply the chatbot limits above.
• Evidence check: Is there an evaluation set and a baseline to compare against?
• Exit check: What result ends the pilot, and who decides?

How Agnotic can help

When staff ask to use ChatGPT, someone has to decide which requests are safe, and Agnotic Technologies helps health IT teams turn those requests into a short pilot list. Through fractional CTO support, Agnotic engineers sort requests by PHI exposure and review load, confirm which OpenAI products and endpoints the design uses, and build the API integration, reviewer queue, evaluation set and logging for the pilots that pass.

For requests that fail the decision list, Agnotic documents why and what would have to change, so the answer to staff is a clear plan rather than a flat no. That record also gives compliance teams one place to see every approved and refused use case.

Sources

• OpenAI Help Center: Business Associate Agreement (BAA)
• OpenAI: Healthcare Addendum
• OpenAI: Introducing OpenAI for Healthcare (8 January 2026)
• OpenAI: Enterprise privacy
• 45 CFR 164.504(e): Business associate contracts
• HHS: Guidance on de-identification of PHI under the Privacy Rule
• FDA: Clinical Decision Support Software guidance (January 2026)