OpenAI Connected ChatGPT to Epic Charts on 1 September 2026, With Read-Only Access
Quentir Medicine Monitor
Evidence-based insights for quantum medicine. Published by Quentir Systems LLC · September 2, 2026.
A clinician preparing for an afternoon appointment spends the first minutes of it reading: the last visit note, the newest labs, the medication list, whatever the specialist sent over. On 1 September 2026 OpenAI said that reading can be handed to ChatGPT, working from the patient's own Epic record.
The announcement was published in OpenAI's newsroom and reported the same day by Unite.AI. Two capabilities ship together. Health organizations can connect their Epic electronic health record environments to ChatGPT for Healthcare, and a separate Healthcare Public Data plugin wires the same workspace to nine official public datasets, among them ClinicalTrials.gov, CMS Coverage, RxNorm, DailyMed and PubMed. Access to the chart is read-only. The model writes nothing back into the record.
Practical takeaway. A regulatory clearance is not what carries this to the bedside. Necessary elements include a chain of ordinary permissions: an administrator who enables the Epic app in an approved workspace, the clinician's own Epic sign-in and existing chart permissions, and a business associate agreement in place between the hospital as covered entity and the vendor as its business associate; the hospital's own HIPAA assessment and clinical governance remain required alongside them. What stands behind the clinical quality is OpenAI's own physician evaluation, which reports 4,363 ratings across 27 clinical use cases, with 99.1 percent of responses graded safe.
What OpenAI announced on 1 September 2026: Epic records read into ChatGPT, and a plugin for nine public datasets
The EHR integration has two shapes. In the first, authorized patient information from a supported record system is pulled into ChatGPT, and the clinician asks questions grounded in that patient's data instead of paging through encounter notes, laboratory results, medication lists and specialist reports. In the second, available in supported deployments, ChatGPT is embedded directly in the EHR layout, so the assistance happens without leaving the chart. OpenAI describes the integration as an addition to existing record workflows, states that Epic systems hold data for a large patient population, and says the access granted is read-only in both shapes.
The Healthcare Public Data plugin is the quieter half of the announcement and the easier one to evaluate. It bundles connectors to nine official public health sources so that a team can work against named datasets, fields, identifiers and versions. OpenAI's examples are concrete: a research team identifying actively recruiting studies on ClinicalTrials.gov and comparing eligibility criteria, a pharmacy team confirming a drug's current label and warnings on DailyMed, a population health team pulling research, active trials and Medicare coverage information together for a diabetes prevention program. Those tasks have checkable answers, which is what makes the plugin the lower-risk piece.
Which numbers OpenAI published: 4,363 ratings, 27 clinical use cases, and a 99.1 percent safety figure the company scored itself
OpenAI says it works with hundreds of physicians across 60 countries, 49 languages and 26 medical specialties to define and measure health answers in ChatGPT, and that those physicians have reviewed more than 700,000 model responses to date. For the connected-record setting specifically, physicians evaluated responses in 27 clinical use cases including pre-visit review, clinical timelines, medication review and handoff summaries. Across 4,363 ratings, 99.1 percent of responses were rated safe. In a separate two-stage evaluation of clinical questions answered against large United States health datasets, more than 93 percent of responses were graded good or better for each of the five connected data sources tested.
Those figures come from evaluation results OpenAI published itself, and the company says so. That provenance sets what the numbers can support. The denominator is ratings, and the announcement does not say whether a single response could receive several of them, so 99.1 percent of 4,363 leaves approximately 39 non-safe ratings rather than a countable set of unsafe answers. No definition of the safety rating is published: the announcement does not say what the rating scale was, what those 39 ratings concerned, how severity was graded, whether reviewers were blinded to the source of the answer, or how the 27 use cases were weighted in the sample. For a hospital evaluating this, those are the questions that turn a headline percentage into something a safety committee can act on.
Quantum pillar: not applicable. Technology readiness: TRL 7 of 9. Rung seven on the ladder this Monitor uses means a near-final system running in the place it is meant to be used, and the evidence for it here is one health system describing itself as a pilot partner still working out what the tool is good for; the announcement reports no product-specific FDA determination.
Which instrument carries ChatGPT into the chart: the HIPAA business associate agreement
OpenAI's access and controls paragraph is the operative one. ChatGPT for Healthcare combines the health features with enterprise controls: role-based access, single sign-on and audit logs. With a valid business associate agreement in place, customers can use ChatGPT Work, Codex, apps and plugins in the same workspace to support workflows that meet HIPAA obligations. Plugins for Microsoft SharePoint, Google Drive, Salesforce, Slack and other enterprise systems extend the available business context while existing permissions are preserved.
A business associate agreement is a contract between a covered entity, such as a hospital, and a vendor that handles protected health information on its behalf. Its required contents are set out at 45 CFR 164.504(e): the contract establishes the permitted and required uses and disclosures of the information, obliges the vendor to use appropriate safeguards, requires it to report any use or disclosure the contract did not provide for including breaches of unsecured information, flows the same restrictions down to subcontractors, and authorizes the hospital to terminate if the vendor violates a material term. It is a real and enforceable instrument. It is also an information-handling instrument, and it says nothing at all about whether the model's clinical summaries are any good.
That distinction is the one a chief medical information officer should hold onto. The paperwork that lets ChatGPT touch the chart governs privacy and security. The question of whether a handoff summary generated from that chart is accurate sits outside it entirely, and the announcement answers that question with the vendor's own evaluation.
Why FDA's clinical decision support guidance turns on whether a clinician can independently review the basis
The United States has a rule for software that recommends things to clinicians, and it decides who is regulated. FDA's guidance on clinical decision support software sets out how the agency reads the exclusion in section 520(o)(1)(E) of the Federal Food, Drug, and Cosmetic Act. A software function falls outside the device definition only if it meets all four criteria: it does not acquire, process or analyze a medical image, a signal from an in vitro diagnostic device, or a pattern from a signal acquisition system; it displays, analyzes or prints medical information about a patient or other medical information such as peer-reviewed studies and practice guidelines; it supports or provides recommendations to a health care professional about prevention, diagnosis or treatment; and it enables that professional to independently review the basis for the recommendation, so that the professional does not rely primarily on it.
The fourth criterion is where a chart-reading assistant gets interesting. Independent review of the basis means the clinician can see what the recommendation rests on and check it. A summary assembled from a patient's own record may support independent review, because the underlying notes and results are right there in Epic and the clinician can open them; record access alone does not establish that the fourth criterion is met, which also asks for sufficient disclosure of the inputs, logic and data relied upon. Satisfying it in practice is a further step, because a fluent synthesis of forty encounters is exactly the kind of output nobody re-derives under time pressure, and because the criterion also asks that the software or its labeling disclose enough about the basis for the review to be possible. FDA's guidance treats time-critical decision-making as a place where the criterion generally does not hold, on the reasoning that a clinician who has no time to check the basis is relying primarily on the output. Pre-visit review is unhurried. A handoff summary read at shift change moves closer to the line.
How clinicians actually behave when a model shows its reasoning is a separate question from whether the law counts them as reviewing it, and this Monitor has looked at the evidence on that once before. On 6 August 2026 we read a study in which the same AI explanation moved lay readers and physicians in opposite directions, and in which showing the recommendation before the reader had formed a judgment increased anchoring. That piece is about what an explanation does to a reader. This one is about where an integration sits in the record, in the rulebooks and in a hospital's own assurance work. The two meet at the fourth criterion, because independent review is a legal test that rests on a behavioral assumption.
Where this product lands against those four criteria is an open question, and read-only access does not settle it on its own. The criteria apply to a software function rather than to a product, and this product carries several. A pre-visit summary that lays out what a clinician can open and check in the record looks like the kind of function the exclusion was written for. Retrieval across nine public datasets, or a medication review that compresses a label into a recommendation, raises the classification question differently, and the fourth criterion also asks for enough disclosure about the basis for the review to be possible. The announcement describes no such disclosure and reports no FDA determination of any kind.
What ONC's decision support interventions criterion 170.315(b)(11) already asks of predictive decision support inside an EHR
There is a second rulebook, and its reach is narrower than it first appears. It binds developers of health IT modules that carry the decision support interventions criterion, and it separates the predictive interventions a developer supplies with its own module from third-party interventions merely delivered through it. ONC states plainly that a developer is not accountable for populating source attributes for predictive interventions it does not supply, and it leaves the determination of what counts as a predictive intervention to the developer whose module carries that criterion. "Supplied by" reaches far enough to cover some third-party interventions the developer offers with the module, so an assistant embedded in the EHR layout does not fall outside the criterion merely because another company wrote it. The hospital's part in this is procurement diligence: putting the question to the record vendor in writing, and fixing the answer in the contract.
The decision support interventions criterion at 45 CFR 170.315(b)(11) defines a predictive decision support intervention as technology that supports decision-making using algorithms or models that derive relationships from training data and produce a prediction, classification, recommendation, evaluation or analysis. A module carrying the criterion must support the source-attribute fields themselves: for predictive interventions the developer supplies, the developer establishes and maintains the attributes; for interventions a customer supplies, the module must let a limited set of users record, change and access them. The attributes fall in nine categories covering the output, the intended use, cautioned out-of-scope uses, development details and input features, fairness processes, external validation, quantitative performance measures, ongoing maintenance and the update and validation schedule. Developers must also apply risk management practices to each predictive intervention they supply, covering validity, reliability, robustness, fairness, intelligibility, safety, security and privacy.
The nine attribute categories are a useful checklist however the scope question resolves, because they name precisely the things OpenAI's evaluation summary leaves out: external validation by someone other than the developer, quantitative performance measures per use case, and a stated maintenance and revalidation schedule for a model that changes underneath the deployment. Populating them for a given intervention is the developer's responsibility only where the developer supplies that intervention with its module, which is why asking for them belongs in the contract rather than in the expectation.
Which seven health systems are named, and what UCSF's chief executive actually said
The Unite.AI report lists AdventHealth, Baylor Scott and White Health, Boston Children's Hospital, Cedars-Sinai, HCA Healthcare, Memorial Sloan Kettering Cancer Center and UCSF as launch partners for the product. That is a serious list, and it describes association with ChatGPT for Healthcare rather than confirmed operation of the Epic integration at each of the seven, which the announcement does not claim. It is also the list that one same-day report carried, and OpenAI has named a wider set of health partners in its own earlier material, so it should be read as a sample of who is involved. It is worth reading the one direct quotation carefully. Suresh Gunasekaran, president and chief executive of UCSF Health, described his organization as a pilot partner exploring how the integration can help clinical teams understand what has changed and what matters most in a complex patient record. He said the technology "has the potential to reduce time spent synthesizing data and give clinicians more time with patients."
Two phrases in that sentence are doing careful work. "Pilot partner" and "has the potential to" are both hedges, and they are the correct hedges for a product on its first day. A named health system agreeing to pilot something is evidence that the system's leadership considers it worth evaluating. It is not evidence that the evaluation has been completed, and the announcement makes no claim that it has.
How Quentir Reads It
The interesting fact in this announcement is architectural. A general-purpose language model can now read the patient record at organizations that sign for it, and the instrument that admits it is a data-handling contract. A read-only assistant that surfaces information a clinician can open and check has the shape the clinical decision support exclusion describes, and how each of its functions sits against that exclusion has not been established by anyone. The announcement reports no determination.
For a hospital buyer the practical consequence is that the assurance work stays in-house. OpenAI reports no product-specific FDA determination, and the exclusion is assessed function by function, so a hospital cannot read a clearance letter off this announcement and has no basis for assuming one exists. What it has is a vendor-published safety rate, a set of enterprise controls and a contract. Everything else worth knowing has to be generated locally: a shadow evaluation on the organization's own charts, a defined set of use cases the tool is sanctioned for, an explicit boundary around time-critical work, and a monitoring plan that survives the next model update.
Two questions are worth putting to any vendor offering this shape of product, and they are this Monitor's own rather than a published checklist. First, what happens to the safety numbers when the underlying model is updated, and who re-runs them. Second, which specific clinical tasks does the vendor decline to support, stated as a list rather than as a disclaimer. On the evidence released on 1 September 2026, both are open.
The milestone to watch is the first published evaluation of this integration conducted by one of the named health systems rather than by the vendor, on that system's own patients, with per-use-case accuracy reported alongside the safety rate. Until that exists, the sensible reading is the modest one: a well-instrumented reading tool has been placed next to the chart under a privacy contract, at organizations that have the capacity to study it properly, and the study is the part that has yet to happen.
Sources
Primary source: OpenAI, "ChatGPT connects health records and healthcare sources," OpenAI newsroom, 1 September 2026, for the Epic integration and its read-only access, the Healthcare Public Data plugin and its nine sources, the physician evaluation figures, the enterprise controls, the business associate agreement condition and the availability limits. Those figures, the list of seven organizations and the quotation from Suresh Gunasekaran, president and chief executive of UCSF Health, were read here in Unite.AI's same-day report and are attributed to it, OpenAI's own page having declined this Monitor's fetch; that report names seven organizations as launch partners, which records their association with ChatGPT for Healthcare rather than confirmed operation of the Epic integration at each, and OpenAI has named a wider set of health partners elsewhere. The four criteria of section 520(o)(1)(E) and the treatment of time-critical decisions come from FDA guidance on clinical decision support software; the predictive-intervention definition, the nine source attribute categories, the risk management requirement and the scope of "supplied by" from ONC's decision support interventions criterion at 45 CFR 170.315(b)(11); the required contents of a business associate contract from 45 CFR 164.504(e). The earlier study on explanation and anchoring is this Monitor's reading of 6 August 2026. The judgments are this Monitor's own: that a data-handling contract is the instrument admitting this product to the chart, that 99.1 percent of 4,363 ratings leaves approximately 39 non-safe ratings against an unpublished rating definition, that the ONC attribute categories name what the vendor summary omits, and the diligence questions put to any vendor offering this shape of product.