On November 10, 2026, Google Cloud announced "Gemini for healthcare," an AI service for medical workflows, and began offering it in preview to eligible customers in the United States. The product is meant to ease administrative work for healthcare staff, for example by organizing a patient's medical history from electronic health records and drafting the documents needed for insurance prior authorization. However, even though the AI can consult clinical records and draft documents, it is designed so that writing to the electronic health record, issuing clinical orders and finalizing content remain the responsibility of healthcare professionals. Its connections to Epic and Oracle Health are also restricted to read-only access.
There are also limits on the clinical information the AI can access. For instance, the feature that connects to Epic's electronic health records restricts how patients can be searched for, which document formats can be retrieved and how long a record can be. When evaluating how much the AI streamlines document preparation, it is therefore necessary to consider not only how quickly it generates drafts, but also whether it can retrieve the records it needs and how much time people spend filling in any information it could not retrieve.
Healthcare-specific skills support everything from visit preparation to insurance paperwork
Gemini for healthcare combines the general-purpose Gemini agent that Google Cloud announced the previous month with healthcare-specific instructions and connections to existing systems. Rather than developing a new foundation model, it aims to apply existing AI to clinical and administrative work. At its core is a mechanism called "skills," which lets organizations reuse instructions and operational context defined by experts, and which can reflect each healthcare organization's procedures as well as insurers' rules. Google says it retrieves the necessary information while preserving the access permissions of existing systems, and combines this with model selection, auditing of operations and citations of the sources behind its answers.
One specific use is preparation before an appointment. The AI organizes a patient's medical history chronologically and checks for inconsistencies in medication information, making it easier for clinicians to grasp the information they need for care. It is also expected to draft prior authorization requests in line with insurer policies and to point out missing information. If a request is denied, it can draft an appeal based on the clinical record, provided the record supports it.
For benefits-related work, it checks submitted documents against insurance rules and organizes the information so reviewers can examine it more easily. It also supports estimating out-of-pocket costs according to a member's insurance plan. The idea is to handle record searches, checks of insurance conditions and preparation of application documents, which were previously done separately, as one continuous process. These, however, are features and intended uses announced by Google, not measured data showing how much time was actually saved in real clinical settings.
The status of connections to existing systems also varies. It uses the open.epic API for Epic and the Ignite API for FHIR for Oracle Health, while the connection to NextGen Healthcare is under development and is planned to be available within the next few months. Optum's "Coordination of Benefits" and "Network Eligibility" are being tested as limited releases.
The Epic connection limits what information can be retrieved
The Epic electronic health record connector for Gemini Enterprise calls Epic's FHIR R4 API in response to user questions to retrieve clinical information. It uses SMART on FHIR for authentication, relying on each user's own Epic account, so the access permissions configured in Epic apply as they are. It also does not copy Epic data into Google's data stores or index it for search. This design lets it reference the necessary clinical information while maintaining existing access controls.
Having access permission, however, does not mean all clinical information can be retrieved. The specifications for the Epic connector in Google Cloud's official documentation, as of November 11, 2026, state several limits on how patients are searched, how many records are returned, which document formats are supported and how long records can be. The main limits, and what to check when deploying, are summarized below.
| Item | Epic connector limitation | What to check when deploying |
|---|---|---|
| Patient search | Requires a medical record number, an Epic patient ID, or a combination of surname and date of birth. Searching by name alone or date of birth alone is not possible, and each patient must be searched individually | Whether the target patient can be specified accurately. Workflows that require searching across multiple patients are not supported |
| Number of records returned | Up to 50 per page. The total count is not returned, so information may be incomplete when handling large volumes of records | Whether the necessary information can be retrieved without omissions for patients with many records |
| Document formats | PDFs are not supported, and imaging studies and consent information are also not retrievable | Whether needed information is contained in unsupported documents or records |
| Record length | The text of records and reports is truncated beyond roughly 20,000 characters | Whether important information appears in the latter part of long clinical records |
These are a summary of the connector specifications Google Cloud has published, not the results of testing at actual healthcare organizations. For example, if information needed for care is contained in a PDF, this connector cannot reference it. In long clinical records, part of the text may not be retrieved and may not be reflected in the AI's summaries or document drafts. Because the connector does not support displaying or browsing patient lists, users must specify each patient they want to look up.
The key point is that having access permission to an electronic health record is separate from being able to retrieve all the clinical information needed. Even if access permissions are properly managed, documents the connector does not support and information outside its scope may not be part of the basis for the AI's answers. These are, however, the published specifications for the Epic connector, and the same limits do not necessarily apply to other connections such as Oracle Health or to Gemini for healthcare as a whole. Whether other connection methods or individual system configurations can make up for these constraints must be checked in each deployment environment.
No writing to electronic health records; final decisions rest with clinicians
Because Gemini for healthcare treats its connections to Epic and Oracle Health as read-only, the AI does not directly modify the contents of electronic health records. Although generated documents can be exported to tools such as Google Docs or Microsoft Word, this is distinct from writing back into the electronic health record. Entering clinical records, issuing clinical orders, and the final review and confirmation of content remain the responsibility of healthcare professionals. The AI's role is to support them by gathering and organizing the information needed for decisions and by drafting documents.
On security, Google says it uses the access permissions and audit logs of existing systems and attaches citations of source materials to the AI's answers. It also says the product is designed to support compliance with HIPAA, the US health information privacy law, and that it does not use clinical data, user-entered prompts or generated outputs to train or fine-tune Google's foundation models. These are measures for handling patient information and managing access, but they do not guarantee that the AI can retrieve all the necessary clinical information or that its generated content is accurate.
In clinical use, at least two kinds of checks will be needed. One is to compare the information the AI retrieved against the original clinical record to see whether anything is missing; the other is to confirm that the AI has summarized and interpreted the retrieved information correctly. Checking the citations attached to an answer makes it possible to verify consistency with the records it consulted. But citations cannot reveal documents that were never retrieved in the first place, so staff must consult the original electronic health record as needed and fill in any missing information. This is an operational caution drawn from the published specifications, not a report that Gemini for healthcare has actually caused a medical accident or an incorrect decision.
US preview begins; real time savings will be key to adoption decisions
The Gemini for healthcare preview is offered to eligible US customers using Gemini Enterprise Standard or Plus. Google says it will offer both per-user flat-rate subscriptions and usage-based pricing, but neither the official announcement nor the product page discloses specific prices or a general availability date. No announcement about availability in Japan has been confirmed either. What can be assessed at this point rests mainly on Google's descriptions of the features and the technical specifications of each connector.
No independent evaluation of Gemini for healthcare's accuracy or safety by a third party has been found, nor any measurements showing how much working time it has actually saved at deployment sites. A healthcare organization's participation in the preview should be distinguished from proof that the product works. In medical work in particular, even if drafts are generated faster, the overall time savings may not materialize if checking for missing information and correcting errors add more work.
For that reason, evaluating the benefits of adoption requires measuring not just how long the AI takes to draft a document, but the whole process, including supplementing clinical records that could not be retrieved, checking against cited sources, and corrections and final confirmation by clinicians. Being able to link multiple tasks, such as insurance prior authorization and visit preparation, with AI is a distinguishing feature of Gemini for healthcare. How much it actually reduces the workload will have to be determined through verification in real settings.