ChatGPT Health in the EHR - Changing what health systems need to govern

Key Takeaways

• Existing Epic permissions govern chart access, and the connection is read-only. ChatGPT outputs can still influence clinical decisions.
• Responsibilities span the health system, Epic, and OpenAI. Review the agreements and controls that apply to the actual deployment.
• Local validation, monitoring, and reassessment remain necessary. Vendor evaluation results do not establish performance in a particular hospital. Decide before go-live which records will be needed to reconstruct an AI-assisted encounter. Signed evidence can support that reconstruction; retained clinical content and clinical review remain essential.

On September 1, 2026, OpenAI announced a new Epic integration that brings authorized patient information into ChatGPT for Healthcare and a Healthcare Public Data plugin. Health systems considering these capabilities face a practical decision: what access to permit, under what conditions, and with what oversight after deployment.

OpenAI also describes support for using ChatGPT within the EHR workflow, depending on the deployment. UCSF Health is a pilot partner. A separate Healthcare Public Data app connects ChatGPT to nine public healthcare sources, including PubMed, ClinicalTrials.gov, and CMS Coverage. The Epic connection follows each clinician’s existing chart permissions and is read-only: ChatGPT cannot update the record, place orders, or send messages to patients through this connection. Once authorized patient information is available, clinicians can use ChatGPT for Healthcare to generate outputs ranging from summaries to clinical reasoning, including differential diagnosis.

For health systems accustomed to governing what employees may type into a chatbot, direct access to the chart adds new responsibilities. Before enabling the integration, organizations should assign accountability, validate performance locally, and establish what records they will retain if an AI-assisted encounter needs to be investigated.

Shared Responsibility for the Integration

Responsibility for the Epic integration spans OpenAI, Epic, and the health system. The contracts governing the deployment define the parties’ respective obligations and address issues such as liability, indemnification, incident support, and access to records. OpenAI’s standard Services Agreement generally limits each party’s total liability to the amount the customer paid to OpenAI during the preceding 12 months, with specified exceptions, including indemnification and gross negligence or willful misconduct. Negotiated terms may differ. Health systems should review the agreements governing their actual deployment.

OpenAI’s configuration guidelines describe how responsibilities are divided in practice. The health system configures its Epic FHIR endpoint and OAuth application, determines which users or roles can access the Epic plugin, and approves the FHIR resources available through the connection. Clinicians connect using their own Epic credentials, and their existing Epic and patient-chart permissions continue to apply. Epic provides the EHR and access mechanisms, OpenAI provides ChatGPT for Healthcare and the Epic-ChatGPT integration, and the health system determines how the integration is configured and governed.

Security, configuration, validation, monitoring, and incident response therefore span the health system, Epic, and OpenAI. The health system should designate an accountable lead for safety oversight, identify which controls depend on Epic or OpenAI, clarify how relevant changes or failures will be communicated, and determine which records each party can provide during an investigation.

Figure 1: Authorized retrieval and clinical use. Read-only access limits actions in Epic; generated output can still influence a clinical decision.

Governing Clinical Use

The Epic integration operates within a clinician’s existing Epic and patient-chart permissions. Those controls determine which patient information the clinician can access through ChatGPT for Healthcare. The connection is also read-only. Workspace administrators can govern access to apps, roles, and available resources; action controls depend on what an app exposes. These controls should not be assumed to provide a reliable switch that permits visit preparation while excluding treatment recommendations. A health system should verify which restrictions its deployment can actually enforce.

That distinction matters because ChatGPT for Healthcare supports a range of clinical activities. The same patient information that can be used to summarize changes since the last visit can also provide context for clinical reasoning. OpenAI describes ChatGPT for Healthcare as supporting activities including patient-information summarization, review of care pathways, synthesis of medical evidence, and reasoning through differential diagnoses. A read-only connection therefore limits what ChatGPT can do in Epic, not necessarily what it can generate for the clinician.

Clinical risk can arise even with seemingly straightforward record review. A summary may bring together findings from many parts of the chart, but an omitted laboratory result, outdated medication, retrieval failure, or incorrect synthesis can affect a subsequent clinical decision. Our recent analysis examines these issues in greater depth: AI in Healthcare: Familiar Liabilities, New Causes.

Health systems should define what clinicians must review and verify before relying on AI-generated information. Policy, training, and supervision remain essential. Where a workflow records a review acknowledgment, assess how it authenticates the reviewer’s identity and binds the acknowledgment to the specific output. The record provides evidence of the acknowledgment reported by that workflow; it does not establish the quality of the clinician’s review or reasoning.

The same independent-review question arises under FDA rules. Clinical decision support software is excluded from device regulation only if it meets all four criteria in section 520(o)(1)(E) of the Federal Food, Drug, and Cosmetic Act. The fourth requires that the clinician be able to independently review the basis for a recommendation rather than rely primarily on the software. FDA revised its clinical decision support guidance in January 2026, but the revision does not specifically address generative AI. Classification obligations fall primarily on the manufacturer. A health system still benefits from workflows in which clinicians can see the source information behind an output, and the records described below can help show that they could.

Validating and Monitoring the Integration

OpenAI reports that physicians rated 99.1% of responses safe across 4,363 physician ratings covering 27 clinical use cases with connected EHR context. Those ratings are not a count of unique patients or clinical outcomes. In a separate evaluation, more than 93% of responses received an accuracy rating of “good” or better for each of the five public data sources tested; the public-data app offers nine sources in total. These are vendor-reported evaluation results and do not replace local validation.

Validation and monitoring serve different purposes. Validation asks whether the integrated system performs adequately in the organization’s environment at a particular point in time. Monitoring looks for changes, recurring failures, exceptions, and other signals after deployment that may call that assessment into question. Changes in the model, data, configuration, workflow, or how clinicians interact with the technology may all affect whether earlier validation remains applicable.

Local validation must account for the health system’s patients, Epic configuration, documentation practices, and clinical workflows. Vendor testing provides useful evidence, but it cannot establish how those factors will affect performance in a particular organization. Before broader deployment, health systems should determine how the technology performs locally, who is accountable for that assessment, and what findings would require additional testing or reconsideration of deployment. The Joint Commission and CHAI’s Guidance on the Responsible Use of AI in Healthcare, published in September 2025, calls for local validation and ongoing monitoring.

The deployment review should include clinical leadership and patient safety alongside compliance, IT, security, and legal. It should address:

Local validation. Test the Epic-ChatGPT integration using representative clinical scenarios, patient populations, documentation patterns, and Epic configurations. Include realistic failure conditions such as incomplete retrieval, conflicting information, and clinically important omissions, not simply whether the model produces an acceptable response under ideal conditions.

Human review. Define what clinicians are expected to verify and which clinically important errors they can reasonably detect. Human review should not be assumed to compensate for failures that are difficult for the clinician to recognize, such as information that was not retrieved or was omitted from a synthesis.

Monitoring. Establish which observable safety and operational signals will be reviewed after deployment, such as recurring errors, retrieval failures, exceptions, changes in utilization, or reported safety concerns. OpenAI documents conversation and app-call records through its Compliance API in eligible configurations. Determine which fields and exports are available in the actual workspace, how they can be linked to a clinical encounter, and how long they are retained. An access log alone will not reveal every change in clinical use; even a retained conversation may not include the full chart context or every control result.

Reassessment. Define changes that should trigger renewed review or testing. These may include model or Epic-ChatGPT integration changes, changes in Epic configuration or clinical workflow, shifts in the patient population or data available to the system, and safety signals identified after deployment.

Designing the Evidence Path

Runtime evidence adds a source that logs alone do not provide. Glacis Technologies builds infrastructure that applies configured controls to AI interactions routed through its instrumentation and produces signed evidence of what those controls observed and decided. Glacis developed OVERT (Observable Verification Evidence for Runtime Trust), an open specification for representing that evidence so a third party can verify it independently. An OVERT record attests to what the configured instrumentation observed. It does not judge whether an output was clinically correct, and it cannot report on events the instrumentation never saw.

For an Epic–ChatGPT pilot, the first step is to establish which request, retrieval, output, and review signals Epic, OpenAI, and the health system make available. The proposed evidence path in Figure 2 requires an authorized integration point and appropriate configuration; it does not assume a native Glacis connection to Epic or ChatGPT. Where that integration exposes a control point, a configured rule may flag incomplete context or require review before release. A retrospective log export can support investigation but cannot enforce that rule during the encounter.

Sample Case Study: Consider a hypothetical AI-generated visit summary that omits a clinically important laboratory result. If the workflow retains an authorized chart snapshot, the retrieval result, the exact context supplied to the model, and the generated output, an investigator can compare those records to distinguish a result that never reached the model from one it received but omitted from the summary. The comparison must establish what was available at the time of the encounter. If a configured check compares required results with the retrieved context, evidence can also record the check’s result and any escalation or review acknowledgment.

This example depends on retained content and an explicit comparison with the chart. Evidence about the retrieval and review process supports that investigation; it does not replace clinical assessment.

Figure 2: Proposed evidence path for a bounded pilot. Dashed connections depend on exposed or instrumented signals.

Creating an Auditable Record for Liability and Claims

Auditors distinguish between a control’s design and evidence that it operated. In AI-assisted care, a policy requiring clinical review does not establish that review occurred during a particular encounter. Epic audit records, retained ChatGPT conversations and app-call records, health-system workflow records, and signed runtime evidence may each contribute to an investigation. Their fields, coverage, timestamps, and retention must be assessed together. No single record should be assumed to capture the full encounter.

For a disputed encounter, the healthcare organization may need to establish what information the AI retrieved, what it generated, which controls applied, and what the clinician did with the output. Retention and export arrangements should support that reconstruction across the systems involved. Preserve the relevant source content, available model identification, and configuration versions in approved systems, with a reliable way to link them to the evidence record. A digest can help check whether retained content changed, but it cannot reconstruct a missing prompt, laboratory result, or response.

OVERT evidence can support that investigation. A reviewer can check a record’s signature and whether its signed contents have changed, using the expected issuer’s key and the declared evidence boundary. A witness or timestamp can provide additional evidence that a record existed or was included in a log. Verification establishes the integrity of the record. Clinical appropriateness, safety, and the quality of human review require separate assessment.

OVERT is currently stewarded by Glacis. An agreement has been announced to transition the specification to shared stewardship by Coalition for Health AI (CHAI) and the AIGovOps Foundation. The public governance record states that the transition is pending a commencement certificate.

Insurance developments make this evidence increasingly relevant. A September 2026 analysis from the Center for Strategic and International Studies (CSIS) reports that more than 60 property and casualty insurers filed AI exclusions in 2026. At the same time, some insurers are moving toward affirmative coverage: CFC announced in June that it was introducing explicit AI-related language across seven of its insurance products. Health systems should ask their brokers how AI-related claims would be treated under professional liability, cyber, and other relevant policies, and what records an insurer would expect when evaluating a claim. A reliable record can support underwriting and claims review; it cannot override an exclusion or guarantee coverage.

PHI, Patient Notice, and Privacy Risks

Enabling the integration does not automatically authorize a workflow involving protected health information (PHI). OpenAI’s guidance requires an applicable Business Associate Agreement (BAA), appropriate Epic authorization, and an approved workspace configuration. Organizations should confirm which products, features, and connected services their agreement covers. OpenAI states that content shared within ChatGPT for Healthcare is not used to train its models. The review should also address retention, access to conversation records, evidence storage, and any onward transfer of patient information.

The Healthcare Public Data app requires particular care: OpenAI instructs users not to include PHI or patient identifiers in searches sent to public sources. Authorization to retrieve a patient’s chart should not be assumed to authorize sending that information to a separate public-data service. Runtime evidence also needs its own data-minimization, access, retention, and export controls. Where appropriate, records can reference content retained in an approved clinical store rather than duplicating it; the design still requires review of what data each component processes and retains.

A BAA sets terms for a business associate’s handling of PHI under HIPAA; it does not resolve every patient-notice or consent question. Additional requirements can depend on the jurisdiction, the workflow, and the records involved, including substance use disorder records. Recent litigation over ambient AI documentation, discussed in the liability article linked above, concerns issues such as recording and transcription. An assistant retrieving existing EHR data presents different facts. Organizations should assess the notice and consent requirements for each proposed use rather than assuming the rules for ambient recording apply unchanged. Some states now address AI disclosure directly. Texas, for example, requires providers to disclose to patients in writing the use of AI in connection with their health care services or treatment, effective January 1, 2026.

A 90-Day Pilot Plan

For organizations evaluating the integration, start with one defined clinical workflow, such as visit preparation, and a limited group of clinicians. Set the pilot’s boundaries, review requirements, and success criteria before expansion. A 90-day pilot can organize the work into three stages.

Days 1–30. Confirm contractual and PHI requirements, authorized users, approved chart resources, and the actual app configuration. Map the signals and records each party can provide. Select the controls to assess, identify the owner of each, and confirm that any proposed evidence adapter can observe the chosen workflow. Define acceptable clinical performance, required evidence coverage, and conditions for pausing the pilot.

Days 31–60. Validate representative local scenarios, including incomplete retrieval, outdated information, clinically important omissions, and conflicting chart entries. Use synthetic or appropriately authorized cases. Test a missing-result scenario and confirm which records allow a reviewer to distinguish retrieval failure from an omission in the generated summary. Verify that exceptions reach the assigned reviewer and that required acknowledgments are recorded.

Days 61–90. Monitor the chosen signals and exercise an incident investigation using an authorized test encounter. Export and verify the relevant records, retrieve the associated clinical content, and document any gaps. Test a material configuration change and a failure of the evidence path. Expand only if clinical performance and evidence coverage meet the pilot’s agreed criteria, with owners assigned for unresolved issues and reassessment.

Jennifer Shannon, MD, co-founder of Glacis Technologies, contributed to this article. Glacis developed the original OVERT specification and built runtime evidence infrastructure for AI systems in healthcare.

This article was prepared with AI assistance and edited and enhanced by EisnerAmper professionals for accuracy and completeness. All technical content, analysis, and recommendations reflect the knowledge of our team.