Dek: Google Cloud's new healthcare product doesn't diagnose anyone. It reads the chart, drafts the insurance packet and explains the denial, which is where hospitals lose their week.
What Gemini for healthcare is, in Google's own framing
Google Cloud announced Gemini for healthcare this week and put it in preview, not general availability. CEO Thomas Kurian described it as a purpose-built industry solution that extends the universal Gemini agent introduced at Gemini at Work in October 2026.
Read that framing carefully. This isn't a medical model. It sits on clinical, financial and administrative workflows, with a human still signing off, and the tasks it targets are the ones that generate paperwork rather than the ones that generate diagnoses.
Google says clinicians spend nearly 28 hours a week manually reconciling information across disconnected systems. That's Google's own figure, not an independent study, and it's the number the whole product is built around.
The agentic layer, broken into four parts
The architecture has four pieces: healthcare skills written by domain experts, connectors to clinical, financial and operational systems, an open partner set, and one governed platform that can route between models.
The agentic layer is the part that matters. Instead of one assistant that does everything badly, Google is selling narrow agents that each own a task and inherit the permissions of the person using them.
Google Cloud healthcare AI also allows a mix of models. An organization can pair frontier Google models with partner models under the same governance layer, which is a concession to hospitals that already have a favourite vendor for something.
Provider workflows: the patient timeline and chart prep
The first workflow is a longitudinal patient timeline that separates active problems from resolved ones and flags medication discrepancies. Anyone who has prepped for a ward round knows why that's the demo: the history is in four places and one of them is a PDF.
Chart preparation before a visit is the second. The agent assembles what a clinician needs to read before walking into the room, rather than leaving them to scroll.
Those two tasks are unglamorous and they're where the hours go. A tool that saves ten minutes per patient doesn't sound like much. Multiply that by a full clinic list and you've handed a nurse her morning back.
Prior authorization is the workflow to watch
Prior authorization is the insurance step where a clinician has to justify a treatment before a payer will cover it. It's slow, it's repetitive, and in the United States it delays care that clinicians have already judged necessary.
Google's product assembles an authorization packet against the payer's policy before submission, which means the agent reads the rules first and builds the case to match. When a denial lands, it can draft an appeal grounded in the clinical record and the plan's policy.
Outside the US, the same work has different names. In England it arrives as referral letters and discharge summaries, and none of those documents read like the payer policy this product was built around.
That's a real change to the workflow, and it's also the workflow where an error is expensive. A packet built against the wrong policy version doesn't just fail. It wastes the two weeks the patient didn't have, and nobody in that room can give them back.
Payer-side review runs on the same rails
The payer side gets a mirror of the same tooling. Agents check incoming requests against medical policy, organise findings for clinical reviewers, and explain benefits and costs using the member's own plan documents.
Put both sides in one product and the obvious question arrives fast: if the same vendor sells to the hospital and the insurer, whose policy does the agent read first? Google hasn't addressed that, and it isn't a technical question.
How Google governs Gemini for healthcare agents
The governance claims are specific, which is unusual. Every agent gets a distinct identity, inherits each user's existing role-based permissions, and enforces need-to-know boundaries across users, sub-agents and workflows. Audit logging and verifiable citations exist so a reviewer can check where an answer came from.
Identity per agent is the design choice worth noting. A shared service account would have been easier and would have made every audit trail useless, because you couldn't tell which process touched which record.
HIPAA support isn't HIPAA certification
Google says the platform is built to support HIPAA compliance, with enterprise-grade access controls, end-to-end audit logging and citations. It doesn't say the product is HIPAA certified, and those are different claims.
HIPAA is a US law, and compliance is something a covered entity demonstrates, not something a vendor stamps on a box. A vendor can give you the controls. Your organisation still owns the risk.
If you're outside the US, the equivalent question is local: which data protection agreement covers a preview, and where does the processing happen? Google hasn't published answers for either.
What hospitals will ask before they sign
Four open questions.
None has a public answer yet. Which EHR and claims systems are connected on day one? What does a preview cost once the preview ends? Who carries liability when an agent builds a packet around a policy that changed last month, and do clinicians get a say in how the agents are deployed?
The preview status answers one of them indirectly. No pricing was published and no production contracts were announced, so the sensible move for a hospital IT team is to read the governance documentation and wait for named customers.
That's the honest state of it. Google has described a plausible product for the worst part of clinical administration, and it has published the controls it thinks will satisfy a compliance officer. Until a health system puts its name next to a deployment, the 28-hour figure remains a vendor's argument rather than a result.
