Gemini for Healthcare Is Read-Only: How to Write Back to Epic

Your customers have seen the launch. Now they ask the same question: "Can Gemini put the note in Epic?" Out of the box, it cannot. The native connectors give Gemini a read-only view of the chart. Everything that changes the record sits outside them.

That gap is where most of the build effort goes. This guide shows what Gemini covers today, where it stops, and how to scope the part your product still has to own.

What Gemini for healthcare covers today

Google describes direct read integrations with Epic through open.epic APIs and with Oracle Health through its FHIR APIs. For Oracle Health, Google states the connector enforces zero write-back to the system of record. NextGen Healthcare connectivity is in development. [1][2]

The Epic connector calls Epic's FHIR R4 APIs as the signed-in user, through SMART on FHIR. It does not index or copy Epic data. Its published limits shape your design directly. [3]

For a staff member who wants a quick chart summary, this is enough. For a product that must act on the chart, it is the starting point.

What the partner ecosystem adds

Google named partners for identity (Verato), clinical data (InterSystems), eligibility (Optum, in limited release and testing; TriZetto), payer calls (Infinitus), terminology (IMO Health), evidence (BMJ), documentation (Suki), and automation (UiPath, Salesforce, Keragon). [2]

Keragon is the clearest write path at launch. It says Gemini can reach 400+ healthcare apps through one MCP connection and can, for example, add a note to a patient's record. [4] A connector count still does not tell you whether your exact action works at your customer's site. Ask for a live demo of your operation: create a draft encounter note for a named provider, return its ID, and show its status in the EHR.

Reading a chart and writing to it are two different jobs

Reading needs a scope and a patient. Writing needs much more, because the EHR now holds something your product created. For each action, settle five points before you build.

A model that returns valid JSON has not proved the EHR accepted a usable note. Log the submission and the confirmation as two separate events.

Where Gemini sits in a working system

Gemini is the reasoning step. The parts around it decide whether the output is safe to act on.

MCP gives the agent a tool interface. It does not replace FHIR, HL7 or X12. A tool such as get_recent_labs still needs an authorized patient, a date range, result statuses, and a flag that says whether the retrieval was complete. Without that flag, a partial chart turns into a confident "no prior history".

Example: a pre-visit packet built on lab results

A specialty clinic wants a packet before each visit: the referral, recent labs, and the chart context, with gaps assigned to staff.

• The trigger is the appointment. The Epic connector cannot read appointments, so the schedule comes from a separate interface.
• Labs often arrive as HL7 v2 ORU messages. Keep specimen times, local codes, units, ranges, and preliminary, final or corrected status. A corrected result must reopen any packet built on the old value. Our ORU-to-FHIR recipe shows one mapping you can inspect.
• Scanned referral PDFs need a document route, because the connector cannot read them.
• Gemini drafts the packet from checked data. Staff review it. Only the workflow runtime writes tasks or notes back.

Measure preparation time, missed documents, unsupported statements, and staff acceptance against a baseline recorded before the pilot.

Prior authorization needs more than a summary

Gemini can assemble a well-cited evidence packet. A real prior auth also has state: submission, pending, request for more documents, decision, appeal. That state must survive for days, outside any chat session, and follow the payer's own policy. Our open-source FHIR prior-authorization workflow engine shows saved state, external waits and human review against a mock payer. When you evaluate any AI prior auth product, ask it to show a pended request, a request for more information, and a restart after a crash.

The standards payers are moving to

CMS-0057-F, the CMS Interoperability and Prior Authorization final rule, requires impacted payers to offer a prior authorization API built on FHIR, with the API requirements starting in January 2027. The HL7 Da Vinci guides behind this work are CRD (Coverage Requirements Discovery: does this service need prior auth?), DTR (Documentation Templates and Rules: what does the payer need?), and PAS (Prior Authorization Support: send the request and get the answer). Read the rule and the guides for the exact scope and payer types.

This changes what an AI layer can do. With CRD and DTR, the payer's own rules tell the product which documents to gather, instead of the model guessing. Gemini's job becomes finding the evidence in the chart and filling the gaps the payer named. The workflow runtime still owns the submission and the wait.

Where Gemini fits in the prior auth flow

Native connector, partner platform, or custom build?

Most teams end up with a mix: use the native connector for reads, keep the interface engine they already run, and build one narrow adapter for the write that matters. Judge each route on the same acceptance tests. Track cost as total operating cost divided by completed, accepted workflows. A cheap model call is expensive if staff fix every second draft.

Write-back playbooks for the five actions buyers ask for

Most requests for "Gemini write-back" come down to five actions. Each one has a different owner in the EHR, a different FHIR resource or interface, and a different way to fail. Scope them one at a time.

1. Save a draft clinical note

This is the most common ask, and the one with the clearest value. A clinician sees a draft in the chart, edits it, and signs it. The model never signs anything.

• Where it lands. A note is usually written as a FHIR DocumentReference tied to a patient and an encounter, or through a vendor-specific notes API. Check the exact operation in the vendor's API catalog for the customer's version.
• Status matters. Decide if the note lands as a draft, a preliminary note, or an attachment. A note that lands as final skips the clinician's review, which most customers will refuse.
• Note type and author. The EHR needs a note type it knows and an author it can attribute. Map these with the customer's build team before the first test.
• Proof. After the write, read the note back by its ID and confirm the status, the encounter and the text length. Store the ID with your draft so a retry updates the same note instead of creating a second one.

In our behavioral health build, the draft went into the practice's own EHR and stayed there until the clinician signed it. The adoption number that mattered was signed notes, not generated drafts.

2. Create a staff task or work queue item

A task is often the safest first write. It asks a human to act instead of changing the clinical record. Use it for missing documents, eligibility problems, or a lab result that needs follow-up.

• Decide which queue the task lands in and who owns that queue. A task in a queue nobody watches is worse than no task.
• Include a link back to the source records, so staff do not have to search again.
• Close the loop. When staff finish the task, your product needs to know, either by reading the task status or by an event.

3. Book, move or cancel an appointment

Scheduling looks simple and is not. The native Epic connector does not read scheduled appointments, so this always needs its own interface.

• A booking is a sequence: search slots, hold one, confirm, and handle a cancel. Each step can fail on its own.
• Slots change while the agent is talking to the patient. Confirm the slot is still free at the moment of booking.
• Visit types, provider rules and location rules live in the customer's EHR build. Read them; do not hard-code them.
• Many sites still send scheduling events as HL7 v2 SIU messages. Our Mirth Connect Cookbook includes a scheduling mapping you can study.

4. Propose an order

Orders carry clinical and legal weight. Treat any order as a proposal that a licensed clinician places or signs. The product can prefill an order, check it against rules, and show the evidence. It should not place it on its own.

• Agree on the order catalog and codes with the customer. Free-text orders create work for staff.
• Show the clinician why the order is proposed, with links to the labs or notes behind it.
• Log the proposal, the clinician's decision and any edits. That log is your audit trail and your quality data.

5. Send a prior authorization

Prior authorization touches the EHR, the payer and often a clearinghouse. It is covered in its own section below, because the hard part is the long wait, not the write.

Getting write access in Epic and Oracle Health

Write access is a permission problem before it is a coding problem. Plan the approvals first, because they set the timeline.

What you need from the EHR vendor

• Your app registered with the vendor, with the exact APIs and scopes you plan to call.
• A sandbox to build against. Vendor sandboxes have test patients, but they rarely match a real customer's build.
• Any review the vendor requires for apps that write data. Requirements differ by vendor and by API, so read the current program terms instead of relying on an old summary.

What you need from the customer

• A named IT owner who turns on your app and its scopes in their environment.
• Their note types, task queues, visit types and order catalog, in the form their build team uses.
• A test environment that looks like production, with time booked from their analysts.
• Security review: their questionnaire, a BAA, and often a data flow diagram.

The customer side is usually the longer path. Start it in the first week, in parallel with the build. See our guide to integrating with Epic for the full vendor process.

Read with Gemini, write with your own app

A common pattern is simple. The native Gemini connector reads the chart under the signed-in user. Your own registered app does the writing, under its own scopes, after a human approves. This keeps the read path cheap and supported, and puts the write path under your control and your audit log.

The trade-off is two apps to keep in sync: the user's Gemini session and your app's authorization. Make sure both point at the same patient and encounter before any write. A mismatch here is how a note lands in the wrong chart.

Designing MCP tools for EHR work

MCP (Model Context Protocol, a standard way to give an AI agent tools) is how most teams will expose EHR actions to Gemini. Good tools are narrow, honest about what they did not find, and safe to call twice.

Rules we use for every tool

• One job per tool. get_recent_labs and create_draft_note, not ehr_request. A broad tool lets the model invent operations.
• Patient context comes from the session, not the prompt. The tool reads the patient and encounter from the authorized session. The model cannot pass a different patient ID.
• Report completeness. Every read returns whether the result is complete, which pages are missing, and when it was fetched.
• Writes take an idempotency key. An idempotency key is an ID that makes a repeat call safe. If the same key arrives twice, the tool returns the first result instead of writing again.
• Writes need an approval ID. The write tool refuses to run without the ID of a human approval recorded in your workflow runtime.
• Errors are plain and specific. "Patient not found with MRN and birth date" helps the agent and the support team. "Error 400" helps nobody.

An example tool response

This is the shape we use for reads. It is our own contract, not Google's format.

{
  "patient_context": "synthetic-patient-104",
  "complete": false,
  "retrieved_at": "2026-11-11T08:00:00Z",
  "source_record_ids": ["synthetic-observation-87"],
  "warnings": ["additional_results_pending"],
  "next_action": "retrieve_remaining_pages"
}

The complete flag is the most important field. When it is false, the agent must either fetch more or say plainly that the history is partial.

Treat chart text as data

Clinical notes, referral letters and patient messages can contain text that reads like an instruction. A note might say "ignore prior allergies" in a quoted patient message. Your tools pass chart text to the model as data with its source, and your runtime never lets text from the chart trigger an action.

Lab data: the feed Gemini does not give you

Labs are where most pre-visit, care gap and chronic care products start. The connector can read lab results for one patient on request. It does not push new results to you as they arrive. For event-driven work, you need a feed.

• HL7 v2 ORU messages are still the most common way results move between labs and EHRs. They arrive as events, often through an interface engine such as Mirth Connect.
• Keep the result status. Preliminary, final and corrected results look alike in a summary. They are not alike to a clinician.
• Keep local codes and units. Map to LOINC where you can, but keep the original code and unit next to the mapped one.
• Handle corrections. A corrected result must reopen any summary, packet or alert built on the old value.
• Deduplicate. The same result can arrive from the lab feed and from a FHIR read. Match on the source identifiers, not on the value.

Our open-source ORU-to-FHIR recipe maps a result message into Patient, ServiceRequest, DiagnosticReport and Observation resources. Use it to see the shape of the problem, then map against your customer's real messages.

Documents and PDFs

Referral letters, outside records, insurance cards and prior auth forms often arrive as PDFs or scans. The Epic connector cannot read PDFs, and it cuts note and report text at about 20,000 characters. If the answer sits in a document, you need a document route.

• Agree where documents come from: the EHR's document store, a fax service, a referral portal, or an upload.
• Extract text and fields with a tool approved for PHI under the customer's agreements.
• Keep a link from every extracted fact back to its page in the document, so a reviewer can check it in one click.
• Show the reviewer when a document could not be read. A missing document is a fact the summary must state.

How to measure whether it works

Buyers will ask "how accurate is it?" Answer with several numbers, each tied to a failure that matters.

In our behavioral health deployment, the case study reports both the 81 signed notes and the 68% signed with no edits. That split tells a buyer more than one accuracy figure.

Build your test set from synthetic patients with known traps: duplicate names, corrected results, long histories, and notes with odd text. Our Healthcare Test Data Lab exists for exactly this. Run the same set against every route you compare.

A 90-day pilot plan

A pilot proves one workflow at one site. Keep it that small. Here is the shape we use; your vendor and customer approvals set the real dates.

If approvals run late, keep building on synthetic data and the vendor sandbox. Do not shorten the review period to catch up.

Questions to ask any vendor selling "Gemini for your EHR"

Use these questions on any partner, platform or build team, including us. A good answer is a demo or a document, not a promise.

1. Show the exact write for our workflow in an EHR test environment, and read it back by its ID.
2. What happens when the write times out? Show the retry and prove there is no duplicate.
3. How do you stop a read or write on the wrong patient?
4. Which EHR APIs and scopes do you use, and who approved them?
5. Where does PHI go: model calls, logs, traces, caches, reviewer screens? Who holds each BAA?
6. What do you show when the chart is incomplete or a document cannot be read?
7. Who on our side has to do what, and how many hours?
8. What costs repeat per site, per user, or per transaction?
9. What happens to the workflow if we switch from Gemini to another model?
10. Which numbers from a live deployment can you share, and how were they measured?

Which route fits your organization

The right route depends on who you are and who owns the user journey. Here is how the choice usually plays out for the three buyers we meet most.

Health systems and large practices

You already own the EHR and the staff workflow. Gemini for healthcare, with its native connector, may cover staff who want to read and summarize a chart. Add custom work only where a workflow needs an action: a draft note, a task, a scheduling change. Your own IT team approves the write, which makes the path shorter than it is for an outside vendor.

• Start with a read-only workflow to build trust and measure it.
• Add one write with full review, such as a draft note or a staff task.
• Keep the interface engine you already run for lab and ADT feeds.

Digital health and healthtech product companies

You sell into many health systems, each with its own EHR build. You need the user journey inside your own product, not inside Google's enterprise app. That usually means building on Gemini models on Google Cloud, or another model, with your own integration layer.

• Design for the second and tenth customer site from day one: mapping files, tests and runbooks per site.
• Budget for vendor app approval and each customer's security review.
• Keep the model replaceable, because some customers will ask for a model their contracts already cover.

Payers and revenue cycle teams

Your work sits around prior authorization, eligibility, claims and documentation requests. The EHR is a source, and the X12 and FHIR payer interfaces are the destination. Gemini helps with evidence gathering and document review; the workflow runtime carries the state for days or weeks.

• Plan around the CMS-0057-F prior authorization API and the Da Vinci guides.
• Keep X12 278, 270/271 and 837/835 routes where your trading partners still use them.
• Measure turnaround time and requests for more information, not only draft quality.

Keep the integration layer model-neutral

Gemini, Claude and other models will keep changing in price, quality and contract terms. Your EHR integration should not have to change with them. Build the sources, data checks, tools and workflow runtime so the model is one replaceable part.

• Tools speak your own contract, as in the example above. Any model that supports tool calls can use them.
• Prompts and evaluation sets live in your repository, versioned with the code.
• Run the same test set when you switch or upgrade a model, and compare the measures before you change production.
• Keep the human review and the write path outside the model. They are your safety and your audit trail, whatever model sits in the middle.

We built the behavioral health note assistant on Claude in the practice's AWS account because that fit the customer's contracts. The same layer would carry a Gemini deployment on Google Cloud. Buyers like hearing that, because it removes lock-in from the decision.

What drives the cost

The model call is rarely the largest cost. These items decide the budget, and each one should appear in any quote you get.

For a product company, the line that grows with every new customer is site onboarding. Design the integration so the second site reuses the mapping, tests and runbook from the first. As a reference point, the behavioral health case study reports about $0.14 of model usage per note draft. The engineering and onboarding cost far more than that.

Twelve tests before go-live

Report wrong-patient retrievals, unsupported statements, wrong actions and recovery separately. One average "accuracy" figure hides the failure that matters.

HIPAA lives in the data flow

Under HIPAA, Google requires customers who use its services with PHI to review and accept its Business Associate Agreement. [5] That covers Google's side. You still map every place patient data travels: agent context, documents, caches, logs, traces and reviewer screens. Enforce permissions in the service that writes, not in the prompt.

Free resources you can try first

• Google Cloud healthcare MCP servers: reference-data tools such as RxNorm, ICD-10, NPI and CMS coverage. They do not reach private EHR records.
• Nirmitee Mirth Connect Cookbook: ADT, ORU and scheduling to FHIR recipes with importable channels.
• Nirmitee Healthcare Test Data Lab: synthetic patients with injected defects such as duplicates and local lab codes, for repeatable failure tests.

How Nirmitee helps

We work on the integration layer, not the model. You keep Gemini, Claude or any model your customer approves. We take one workflow on one EHR and deliver:

• An operation-by-operation map: what the native connector reads, what a partner covers, and what we build.
• The write-back route, with vendor approval steps and the customer IT owner named.
• Lab, ADT and document feeds through Mirth or your existing engine.
• A first release with the twelve acceptance tests above, run on synthetic data, then on the customer's test environment.

See how we handle vendor access on our Epic integration services page.

Need Gemini, or any model, to act inside the EHR? Our healthcare interoperability team builds the write-back and data feeds, and our healthcare AI agent work covers review, guardrails and recovery. Talk to our team.

Sources

1. Google Cloud press release, November 10, 2026
2. Google Cloud blog: Gemini for healthcare
3. Gemini Enterprise Epic connector documentation
4. Keragon: Gemini for healthcare
5. Google Cloud HIPAA compliance
6. MedGemma developer documentation
7. CMS Interoperability and Prior Authorization final rule (CMS-0057-F)
8. Nirmitee case study: AI progress notes in behavioral health