How Healthcare Teams Connect EHR Data to ChatGPT

Healthcare teams can now bring authorized Epic electronic health record (EHR) context into ChatGPT without copying chart data by hand. OpenAI released the connection on September 1, 2026, alongside nine public healthcare data apps. The Epic connection is read-only, inherits each clinician's existing permissions, and can sit either inside ChatGPT or, in supported deployments, inside the EHR workflow. The payoff is less time spent piecing together notes, labs, medications, and specialist updates. The condition is non-negotiable: every answer remains a draft until a clinician checks the source record, its dates, and what may be missing.

The short answer: use two guarded data lanes

For this release, "connect the EHR" means configure OpenAI's Epic plugin for an approved organizational workspace. It does not mean ChatGPT can connect to every EHR. The plugin retrieves only the chart information the signed-in Epic user may already access, and it cannot write back, place an order, send a patient message, or widen chart permissions. OpenAI's Epic setup guide is the source of truth for eligibility and configuration.

The second lane is the Healthcare Public Data plugin. Its nine read-only apps search PubMed, ClinicalTrials.gov, DailyMed, RxNorm, openFDA, CMS Coverage, CMS Open Data, Medicare Care Compare, and the NPI Registry. These apps search public information, not patient charts. Patient names, medical record numbers, dates of birth, member numbers, and other identifiers do not belong in those searches.

Think of the setup as two doors into one clinical workroom. The Epic door opens with each clinician's own badge. The public-data door opens onto a reference library. Moving a patient identifier through the library door is still the wrong route, even when the workspace has a Business Associate Agreement.

A deployment checklist that can survive security review

The right deployment artifact is not a screenshot of a useful answer. It is a chain of evidence showing which data was eligible, who could reach it, how access was constrained, what the clinician verified, and what happened when context was incomplete.

1. Confirm workspace and legal eligibility

Start with a written go or no-go decision. The Epic plugin is available only in approved ChatGPT for Healthcare and HIPAA-enabled Enterprise workspaces, subject to the organization's rollout and Epic configuration. It is not available to individual ChatGPT for Clinicians accounts.

Before protected health information (PHI) enters the workflow, confirm the applicable Business Associate Agreement (BAA), the contract governing covered handling of PHI, plus the eligible workspace and functionality, the Epic authorization, and any agreements required for the intended use. Feature availability alone does not establish BAA coverage. OpenAI's HIPAA eligible functionality list is deliberately specific, and it notes that improved memory is not covered by the BAA and should not receive PHI if an administrator enables it.

Your approval record should name four owners: the workspace owner, the Epic administrator, the privacy or security owner, and the clinical owner who can stop the pilot.

2. Inventory the sources before connecting them

Write a source matrix with one row per system or app. For Epic, record the environment, approved FHIR resources, patient population, user roles, and whether ChatGPT will run in its own workspace or in a supported EHR layout. FHIR is the standard interface address used to request health-record resources. It is a doorway, not permission by itself.

For public data, approve each of the nine apps separately. Plugin availability, app enablement, role permission, and user connection are separate switches. Installing the plugin does not automatically connect every app. The public-data setup guide also warns that a request may leave the workspace for the organization operating the source, so retention and data-residency assumptions need their own review.

Put a bright line in the matrix: Epic can carry authorized patient context. Public-data searches cannot carry PHI. If a workflow needs both, ask the public question in general terms, then let the clinician compare the cited public answer with the chart inside the approved patient-context workflow.

3. Bind access to real identity

The workspace and Epic administrators configure the EHR app with the organization's FHIR R4 base URL, OAuth client ID, OAuth client secret, and the exact callback URL shown during setup. OAuth is the sign-in handoff that lets Epic grant access without putting a password into a chat.

Each clinician then connects their own Epic account. Installing the plugin for a role does not connect anyone's account, and it does not expand that person's Epic permissions. Credentials, client secrets, and access tokens stay in the approved setup and sign-in flows, never in a ChatGPT conversation or Codex task.

Test joiners, role changes, and leavers before the clinical pilot. SAML single sign-on and SCIM account provisioning can handle the workspace identity lifecycle, but the acceptance test should also prove that a user removed from an Epic role loses the corresponding chart access through ChatGPT.

4. Make least privilege concrete

"Read-only" reduces risk, but it is not the same as least privilege. A read-only user can still see too much if roles and scopes are broad.

Set the Epic plugin to Available or Installed only for approved roles. Review every OAuth scope with the Epic administrator. OpenAI documents common read scopes for patients, conditions, allergies, medication requests and dispensing, observations, documents, diagnostic reports, encounters, and related binary files. Add scopes for appointments, procedures, immunizations, or care plans only when an approved workflow requires them.

For public data, grant each app only to the roles that need it. A pharmacy team may need DailyMed and RxNorm. A research team may need PubMed and ClinicalTrials.gov. Neither automatically needs every CMS dataset. Record who approved each permission and when it will be reviewed again.

5. Design clinician verification into the output

Every patient-context template should force five fields:

1. What changed.
2. Supporting chart items.
3. Relevant dates.
4. Missing or unavailable context.
5. Clinician decision and sign-off.

OpenAI says the Epic response points back to supporting chart information and instructs clinicians to review the underlying record and relevant dates before relying on it. That source check is the control. A polished summary without traceable chart support should fail review.

OpenAI reports that physicians rated 99.1% of 4,363 responses safe across 27 connected-EHR use cases. That is useful evaluation evidence, not permission to skip local validation. Safe is also not identical to complete, current, or correct for a specific patient.

6. Capture audit evidence and fail closed on missing context

App conversations are available through the Compliance API, an export interface for governance systems, and app calls are recorded in Compliance Logs. Before launch, verify that the fields your auditors require are actually present. At minimum, your evidence pack should connect the user, role, app, time, source class, use-case template, review outcome, and exception ticket without copying more PHI into a second system than the audit purpose requires.

The fallback must be visible in the workflow. Available data depends on Epic configuration, approved resources, and the user's existing chart permissions. When the patient record or a required resource is missing, the output should say "Missing context," name the absent source category, and direct the clinician back to Epic. It should not fill the gap from memory or from a public-data search.

For a public source that returns no result, narrow or revise the non-PHI query, check the source's stated coverage, and try again later if the provider is unavailable or rate-limiting requests. No result is not evidence that no study, warning, policy, or provider record exists.

Do the business math before a broad rollout

OpenAI does not publish a list price for ChatGPT for Healthcare. Pricing depends on organization size and deployment needs, and Enterprise workspaces draw advanced-feature usage from a shared contract-level credit pool. That means a credible business case needs a quote and a measured pilot, not a generic seat-cost comparison.

Use this equation:

monthly workflow value = completed reviews x verified minutes saved x loaded clinician cost / 60

Then subtract the full operating cost: the enterprise contract, Epic and OAuth configuration, security review, workflow design, training, clinical validation, audit operations, and support. Measure corrected summaries and escalations alongside time saved. A faster draft that creates extra verification work is not a saving.

The nearby market gives one useful price anchor. Freed's official pricing lists its Premier clinician plan, which includes patient context and EHR push, at $119 per month or $104 per month billed annually. That is not a like-for-like health-system price. It does show that clinicians already pay for the job of assembling visit context. ChatGPT's economic question is whether one governed workspace can cover that job across approved clinical, research, and operational workflows without adding another fragmented tool.

Seven use cases, ranked by likely operational return

1. Complex-patient pre-visit review

A primary-care or specialty clinician with a long chart could ask what changed since the last visit, which recent labs deserve review, whether medications changed, and what specialist recommendations remain open. ChatGPT can assemble a draft brief from authorized notes, medications, conditions, encounters, and lab results, then point back to the chart support.

This ranks first because the work repeats before every relevant appointment and consumes expensive clinical attention. The winning workflow is not "summarize everything." It is a short change brief with dates, source links, and an explicit missing-context section.

2. Shift and service handoffs

A hospitalist or covering clinician could request a timeline of recent encounters, active issues, medication changes, and unresolved follow-ups for an authorized patient. The receiving clinician verifies each important point against the chart before accepting the handoff.

The payoff is a more consistent starting point when care moves between people. The failure mode is equally clear: if a note type or encounter is outside the approved scope, the handoff must flag the gap rather than imply a complete record.

3. Medication-change review

A pharmacy or clinical team could compare current medication requests, dispensing records, allergies, recent labs, and relevant notes from Epic, then separately consult DailyMed or RxNorm for public label and identifier information. The patient lane answers "what is in this authorized chart?" The public lane answers "what does the official reference say?"

That separation reduces tab switching while preserving the boundary between PHI and public queries. It does not decide dosing, interchangeability, formulary coverage, or treatment. Those judgments stay with qualified clinicians.

4. Referral and unresolved-issue tracking

A care coordinator could ask for recent referrals, specialist recommendations, and open follow-ups found in the authorized record. The output could be organized as an action list with the supporting note and date for each item.

The payoff is fewer manual searches across a long chart. The coordinator still confirms whether the underlying task was completed elsewhere, because the connected resources may not include every scheduling, messaging, or external-care event.

5. Prior-authorization evidence preparation

An authorization team could use authorized chart context to draft the patient-specific facts that support a request, then consult CMS Coverage in a separate non-PHI public query for the relevant policy version. A human reviewer reconciles the two before anything is submitted.

This can compress the gathering and drafting work, but it cannot determine an individual's benefits. Coverage sources have scope and version limits, and the final request needs the payer's current rules. Smaller practices that are not ready for an enterprise EHR connection may get more immediate value from the simpler workflows in Dental Office Automation With AI.

6. Trial and evidence screening

A research team could use ClinicalTrials.gov to identify recruiting studies and compare eligibility criteria, while PubMed supplies related research. A clinician could then compare those public criteria with an authorized chart without placing patient identifiers into the public-data request.

The payoff is a faster first pass over fragmented sources. Trial status and eligibility still need confirmation with the study team, and source records can change.

7. Population-health program planning

A population-health team planning a diabetes, cardiac, or medication-safety program could bring together public research, active trials, Medicare coverage information, facility measures, and provider records. That can create a sourced briefing for program leaders without using patient-level data in the public apps.

This ranks lower for immediate return because it is periodic rather than attached to every visit, but it may improve the quality and traceability of planning work across research and operations.

Two products worth building around the connection

1. The strongest opportunity: an EHR deployment evidence console

Build a control plane, one place to govern a deployment, for health-system IT, privacy, and clinical governance teams. It would inventory approved sources, roles, Epic scopes, test cases, exceptions, and audit exports, then produce a review-ready evidence pack for each workflow release.

The demand signal is unusually commercial for a narrow infrastructure job. "EHR integration" receives about 590 US searches a month with a $42.25 cost per click. "EHR integration services" receives about 140 with an $80.68 cost per click and a top-of-page bid as high as $78.96. Buyers are already looking for help and vendors are paying heavily to reach them.

The smallest sellable version supports one Epic environment and one ChatGPT workspace. It imports or records the approved FHIR scopes and role-based access control (RBAC) matrix, runs a fixed acceptance-test library, stores sign-offs, and exports an exception report. The honest catch is a long enterprise sales cycle and constant platform change. The product cannot replace a BAA, local risk analysis, or clinical accountability. Its moat has to be the quality of its evidence model and implementation library, not a thin dashboard.

2. A source-checked pre-visit workflow pack

Build a set of reusable ChatGPT for Healthcare templates for complex-care clinics, paired with a review protocol. Every brief would include changes, medications, labs, follow-ups, chart references, dates, and a "Missing context" block before clinician sign-off.

"AI medical assistant" receives about 140 US searches a month, carries commercial intent, and has a $24.01 cost per click. Freed's $119 monthly Premier plan includes visit summaries, patient context, and EHR push, which is direct willingness-to-pay evidence for the job, though not for this exact deployment model.

The MVP is three specialty-specific templates, a role map, a source-and-date verification checklist, and a pilot scorecard. Sell it first as a deployment package, not standalone software. The catch is defensibility: templates are easy to copy, and the work becomes valuable only when paired with change management, validation, and specialty-specific governance.

What this connection does not solve

This is a strong fit for synthesis and review. It is a poor fit for autonomous care decisions or silent workflow execution.

• It does not connect every EHR. The documented patient-record integration is Epic.
• It does not write to the chart, place orders, or message patients.
• It does not guarantee complete context. Configuration, approved resources, and user permissions decide what is available.
• It does not turn a BAA into blanket approval for every feature or third-party service.
• It does not make public datasets patient-specific, complete, or clinically decisive.
• It does not remove clinician responsibility to check the source record and dates.
• It does not prove that existing audit fields meet your organization's evidence requirements.

The privacy lesson is the same one that applies to other context-rich ChatGPT features: usefulness grows with access, so permission design and retention boundaries matter more, not less. ChatGPT Computer History Privacy examines that tradeoff in another high-context setting.

The 99.1% safety rating and the greater-than-93% good-or-better accuracy rating for each of five tested public-data sources are promising evaluation results. They are not a substitute for local testing on your roles, resources, specialties, and failure cases.

Frequently asked questions

What does EHR integration mean?

EHR integration means connecting an electronic health record to another approved system so authorized data can move between them. In this ChatGPT release, the documented EHR path is a read-only Epic plugin that follows each user's existing Epic permissions.

How to integrate EHR?

For ChatGPT, first confirm an approved ChatGPT for Healthcare or HIPAA-enabled Enterprise workspace and the required legal coverage. Then coordinate with OpenAI and the Epic administrator, configure the workspace-specific EHR app with the FHIR R4 URL and OAuth details, review scopes and roles, publish the app, and have each approved user connect their own Epic account.

What are EHR integration services?

They are implementation services that connect, secure, test, and operate data flows between an EHR and another system. For this deployment, useful services include Epic app configuration, identity setup, scope and RBAC design, clinical validation, audit mapping, training, and exception handling.

What are three key challenges and issues with EHR?

For an EHR-connected AI workflow, the three most important challenges are incomplete context, over-broad access, and unverified output. The practical controls are a visible missing-context state, least-privilege roles and scopes, and clinician review of the underlying record and dates.

Your Monday move

Put the chief medical information officer (CMIO), privacy lead, Epic administrator, workspace owner, and two frontline clinicians in one working session. Choose one repeated review job, map only the data it needs, and test it first against approved test or training records that include a complete chart, a restricted resource, an expired sign-in, and a missing result. Do not expand the pilot until the output names missing context, source links survive review, access fails correctly, and the audit export answers who accessed what and when.

If you want one of these governed healthcare integrations built for your organization, see AI production systems.