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, 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: 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, 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.
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.
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, 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 — 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 — 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; the September 1, 2026 date, the read-only connection and the 325-million-patient Epic figure from TechCrunch; the nine public datasets from PYMNTS; the 27 use cases, 4,363 ratings and 99.1% safety rating from OpenAI's own announcement; the access controls and the open questions on data processing from MarketScale.