--- title: "OpenAI Wired ChatGPT Into Epic. Where Does the PHI Go?" slug: "openai-chatgpt-epic-ehr-platform-era-healthcare" author: "Mikel Amigot" date: "2026-09-10 12:00:00" category: "Premium" topics: "healthcare AI, EHR integration, Epic, ChatGPT for Healthcare, clinical AI, PHI, HIPAA, health system architecture" summary: "On September 1, 2026 OpenAI connected ChatGPT for Healthcare to Epic — read-only, and OpenAI reports physicians rated 99.1% of responses safe across 4,363 ratings. The 325 million patients is Epic's install base." banner: "" thumbnail: "" linkedin: | On September 1, 2026, OpenAI connected ChatGPT for Healthcare to Epic. Authorized clinicians can pull notes, labs, medications and specialist documentation into ChatGPT, or reach ChatGPT inside supported Epic workflows. The engineering is real and OpenAI's own evaluation is unusually specific: 27 clinical use cases, 4,363 physician ratings, 99.1% of responses rated safe. It is internal, not peer-reviewed. The connector is read-only — nothing is written back into the chart. Two things worth getting right before this becomes a board slide. It is not a 325-million-patient integration. That number is how many patients have records in Epic systems worldwide. Access is granted per organization, per clinician, under permissions the health system already controls. And the interesting question for a CIO is not whether the chart can be read. It is where the reasoning over PHI happens once it is. → A vendor-hosted chat over the chart means protected health information leaves the perimeter to be reasoned over, under a BAA rather than under your own controls → Read-only protects the record from bad writes; it does not change where the data travels → Provenance matters more than fluency — a clinician needs the source system and the as-of date for every retrieved fact → EHR vendors are becoming platforms, which is good; it makes the ownership question sharper, not softer With ibl.ai you own all the code and the data — self-hosted inside your own perimeter, model-agnostic across any LLM, usage-based with no per-seat pricing, deployable anywhere from your own cloud to a fully air-gapped network. #iblai #AgenticAI #EnterpriseAI #HealthcareAI #EHR #ClinicalAI --- ## The Short Answer **On September 1, 2026 OpenAI connected ChatGPT for Healthcare to Epic, letting authorized clinicians pull notes, labs and medications into a read-only chat; OpenAI reports physicians rated 99.1% of responses safe across 4,363 ratings. The 325 million patients is Epic's install base, not a connected corpus. The question for a health system is where the reasoning runs — with ibl.ai you own all the code and the data, inside your own perimeter.** Read-only settles what the model can do to the record. It does not settle where protected health information goes to be reasoned over. ## What did OpenAI and Epic announce on September 1, 2026, and what does it not include? OpenAI connected [ChatGPT for Healthcare to Epic's EHR](https://openai.com/index/chatgpt-connects-health-records-and-healthcare-sources/), so authorized clinicians can pull patient context into ChatGPT or reach ChatGPT inside supported Epic workflows without leaving the chart. The connector retrieves appointment notes, laboratory results, medications and specialist documentation. It is [read-only](https://techcrunch.com/2026/09/01/chatgpt-health-adds-epic-integration-for-clinicians-to-import-patient-data/): the model can read and reason, and writes nothing back into the record. OpenAI shipped a Healthcare Public Data plugin alongside it, reaching nine official datasets including PubMed, DailyMed, ClinicalTrials.gov, RxNorm and CMS Coverage. Two framings circulating about this need correcting. The first is timing. This was announced on **September 1, 2026** — nine days before this post. It is not this week's news, and a health system evaluating it is not early. The second is scale. The **325 million patients** figure is how many people have records in Epic systems worldwide. It is Epic's install base, not a corpus OpenAI connected. Access is granted per organization and per clinician, [governed by existing user permissions](https://www.marketscale.com/industries/healthcare/openais-chatgpt-for-healthcare-is-getting-wired-into-epic), with role-based access controls, single sign-on and audit logs. ## Where does the reasoning over PHI actually run in a vendor-hosted chat over the chart? Outside the hospital. That is the architectural fact underneath the announcement, and it is unchanged by the connector being read-only. In this pattern the record stays in Epic and the reasoning happens in the vendor's cloud. Patient context is retrieved, sent out, and processed on infrastructure the health system does not operate, under a business associate agreement rather than under its own controls. A BAA is a contract. It allocates liability and obligates the vendor. It does not put the compute inside the perimeter, and it is not the same class of assurance as never having exported the data at all. Coverage of the launch was explicit that it does not address where data is processed, whether it is retained, or whether it is excluded from training. Those are the three questions a CIO has to get answered in writing before enabling the connector. The alternative pattern is to invert it: leave the record where it is, and put the reasoning inside the institution's perimeter too. Agents read Epic in place over HL7 FHIR under role-scoped, read-only permissions, and the model runs on infrastructure the health system controls. Both patterns are read-only against the chart. Only one of them keeps PHI inside the boundary the compliance office already defends. ## Is "99.1% of responses rated safe" the number a CMIO should decide on? It is a better number than most vendors publish, and it is still not sufficient on its own. OpenAI reports that physicians rated **99.1% of responses safe across 4,363 ratings** covering **27 clinical use cases** — pre-visit review, medication review, clinical timelines, handoff summaries — an internal evaluation, not a peer-reviewed one. Two things that figure does not tell a CMIO. It does not say what the remaining 0.9% looked like. At clinical volume that residue is not rounding: a rate near one in a hundred, applied to the number of chart reviews a large system runs in a week, produces a workload of unsafe outputs that has to be caught by something. And a safety rating is a property of outputs, not of the deployment. It says nothing about provenance, or about whether the retrieved context was complete. That second gap is the operative one. The connector can return a partial chart because part of the patient's history lives in another health system entirely — [the data problem that constrains clinical AI more than model quality does](/blog/healthcare-ai-bottleneck-is-data-not-models). ## Does the end of the closed EHR era mean a health system owns more of its AI, or less? Less, if the only change is that a closed record now feeds an equally closed model. The platform shift is real and mostly good. EHR vendors spent two decades as sealed systems, and an ecosystem of external tools reading the chart under governed permissions is a better arrangement for patients and clinicians than the one it replaces. But opening the record is only half a transfer of control. If the record opens to a vendor-hosted model, the institution has traded one closed system for a second one sitting between its clinicians and its data. The second one holds the reasoning layer, which is where clinical judgment gets encoded. The durable question is not whether the chart can be read by AI. It is which of the three assets a health system ends up holding: the record, the model, and the code that governs how the first two meet. ## What does clinical AI need beyond a chat window over the chart? Four properties, none of which a stronger model supplies. - **Reasoning inside the perimeter.** The model runs where the PHI already is, so clinical context never leaves the institution to be processed. - **Provenance on every retrieved fact.** A clinician needs the source system and the as-of date for each assertion. An answer without provenance cannot be safely acted on, however fluent it is. - **PHI handling enforced beneath the model.** Role-scoped access bound to the institution's identity provider and complete audit trails, enforced server-side rather than requested in a system prompt. - **Pipelines, not conversations, for multi-step work.** Prior authorization and coding have approval gates and failure branches that [a chat window cannot express](/blog/clinical-ai-workflows-need-pipelines-not-chat). ## How does ibl.ai run clinical AI inside a health system's own perimeter? By deploying the platform where the data already is, rather than sending the data to the platform. With ibl.ai you own all the code and the data. The stack runs on the health system's own infrastructure with full source code access, is model-agnostic across any LLM so the institution can switch providers without rewriting the platform, is usage-based with no per-seat pricing, and can deploy anywhere — your own cloud, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. Agents read EHR platforms including Epic, Oracle Health, Meditech and athenahealth [in place over HL7 FHIR](/solutions/medical-healthcare), under role-scoped, read-only permissions, with every access audited. For a compliance officer the operative property is inspectability: the code that touches PHI can be read, not accepted on assurance. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY. *Related reading: [prior auth is not a question — why clinical AI needs pipelines](/blog/clinical-ai-workflows-need-pipelines-not-chat) — why the multi-step clinical work is the part a chat window over the chart cannot hold, and [healthcare AI's bottleneck was never the model](/blog/healthcare-ai-bottleneck-is-data-not-models) — why a partial record limits an agent more than a weaker model does.* *Sources: the announcement and the Epic connector from [OpenAI's healthcare data post](https://openai.com/index/chatgpt-connects-health-records-and-healthcare-sources/); the September 1, 2026 date, the read-only connection and the 325-million-patient Epic figure from [TechCrunch](https://techcrunch.com/2026/09/01/chatgpt-health-adds-epic-integration-for-clinicians-to-import-patient-data/); the nine public datasets from [PYMNTS](https://www.pymnts.com/news/artificial-intelligence/2026/openai-brings-epic-health-records-to-chatgpt-for-clinicians/); the 27 use cases, 4,363 ratings and 99.1% safety rating from [OpenAI's own announcement](https://openai.com/index/chatgpt-connects-health-records-and-healthcare-sources/); the access controls and the open questions on data processing from [MarketScale](https://www.marketscale.com/industries/healthcare/openais-chatgpt-for-healthcare-is-getting-wired-into-epic).* ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.