Use the current Google health AI surface, not last year’s model list
Google for Health now frames healthcare AI around current Gemini-era models and health-specific model families such as MedGemma and TxGemma. That means architects need to check the present model surface before naming a solution path.
Current model families that matter to GCP healthcare planning
| Model family | Primary role | Why architects care |
|---|---|---|
| Gemini on Vertex AI | General multimodal reasoning and application building | Often the starting point for grounded healthcare assistants and search experiences |
| MedGemma | Open health-focused text and image understanding | Relevant when teams need a health-oriented open model path |
| TxGemma | Therapeutic and life-sciences research support | Useful in research and molecule-development contexts rather than bedside UI alone |
| MedLM | Deprecated legacy medical-language option | Important mostly because old architecture notes may still reference it after its September 29, 2025 deprecation |
MedLM status changed on September 29, 2025
The Vertex AI healthcare model surface is date-sensitive. If a solution blueprint still assumes MedLM as the active default path without re-checking current docs, it is stale.
Google for Health AI models
Official page listing current Google health AI model families including MedGemma and TxGemma.
Review the health AI model catalogVertex AI release notes
Official Vertex AI release notes documenting the September 29, 2025 MedLM deprecation state.
Read the Vertex AI release notesClinical search works best as grounded retrieval over harmonized patient context
Vertex AI Search for Healthcare is most useful when it sits on top of a coherent patient data product instead of raw fragmented records. That is why it is frequently discussed next to Healthcare Data Engine rather than as a standalone search box.
The indexed data shape matters too. Google documents a FHIR R4-oriented schema for Search for Healthcare that includes resources such as Patient, Encounter, Observation, Condition, Medication, and DocumentReference. That makes the retrieval surface more explicit than a generic text search over arbitrarily shaped JSON.
Grounded clinical search pattern
Loading diagram...
The practical lesson is that retrieval architecture matters as much as model choice. Search quality improves when the system can pull coherent patient context, preserve provenance, and present results in a way that clinicians can review rather than blindly trust.
Search for Healthcare has product and clinical boundaries
Healthcare search apps are created in the US multi-region, and Google positions them as retrieval and summarization aids over existing medical information rather than direct diagnosis or treatment without licensed-professional review.
GA announcement for Vertex AI Search for Healthcare
Official Google Cloud announcement of general availability for Vertex AI Search for Healthcare and HDE.
Read the GA announcementCreate a healthcare search app
Official setup guide for Search for Healthcare, including location and app-creation details.
Review healthcare search app setupSearch healthcare data
Official guide covering healthcare search retrieval behavior and intended-use boundaries.
Read the healthcare search guideFHIR schema reference for healthcare search
Official schema reference for the FHIR R4 resource surface used by Search for Healthcare.
Review the FHIR schema referenceAgentic workflow claims still need policy, review, and architecture boundaries
Google Cloud now documents healthcare-oriented generative AI reference architectures, including utilization-management workflows. These are useful because they show how retrieval, policy evaluation, orchestration, and review stages fit together instead of pretending one prompt replaces the rest of the process.
Google also publishes a healthcare search checklist that emphasizes source quality, evaluation, and clinical-review readiness. That is a useful counterweight to loose agentic claims because it frames rollout as an evidence and governance exercise, not just an application demo.
- Ground outputs on approved enterprise data instead of free-floating prompts
- Keep approval steps visible for high-stakes clinical or payer decisions
- Separate summarization from final adjudication or patient-facing action
- Log prompts, evidence, and model outputs for audit and tuning
Reviewed agentic workflow for a healthcare determination
Loading diagram...
This is the architectural boundary that keeps the workflow defensible. The system can retrieve and draft, but the final determination still sits with a reviewer who can reject weak evidence, escalate edge cases, or route the case back for more information.
Good healthcare AI architecture is conservative on purpose
The goal is not to prove maximum autonomy. The goal is to make retrieval, reasoning, and human oversight explicit enough that the workflow stays defensible.
Utilization review reference architecture
Google Cloud Architecture Center guidance for a healthcare generative AI workflow with review and orchestration steps.
Read the reference architectureChecklist for healthcare search apps
Official Google checklist covering clinical-quality, evidence, and review considerations for healthcare search deployments.
Review the healthcare search checklistKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.