FHIR Grounding, SMART, and RAG

Healthcare agents need more than a vector store. They need current patient context, role-aware authorization, and a deliberate rule for which knowledge sources can influence the answer or next action.

A practical grounding stack usually combines live FHIR retrieval, approved operational data such as schedules or tasks, and a narrow document corpus such as policy, pathways, or guideline excerpts. This lets the system synthesize an answer while preserving where each part came from.

The first gate is identity resolution. Before retrieving anything else, the workflow should confirm which patient, encounter, or case the task refers to and stop if identity remains ambiguous or conflicting.

View full size

Source: Google Cloud choose an agent design patternLast verified: 2026-03-12

Agentic workflows work best when FHIR access is explicit. Instead of giving a model a broad “read everything” capability, expose task-oriented resource reads or drafts with clear SMART scopes and known response shapes.

SMART launch context matters as much as scopes. If the app launches with the patient, encounter, practitioner, or task already identified, the workflow can narrow retrieval immediately instead of reconstructing context from chat text and risking the wrong chart.

Before passing patient context to a model, normalize it into a compact structure that preserves identifiers, timestamps, and provenance. That allows downstream reviewers to inspect the same evidence bundle that influenced the answer or proposed action.

That compact bundle should retain recency tags such as observation timestamps, medication status dates, and the implementation guide or profile that shaped the resource. Those details help reviewers decide whether the evidence was current enough for the task.

The highest-risk FHIR mistake is not a bad summary. It is a silent mutation of the clinical workflow. In safer agent designs, the model does not jump straight from retrieval to authoritative chart changes. It creates a reviewable work item, carries forward the supporting evidence, and preserves a machine-readable trace of what happened.

Conditional writeback is part of that safety model. When a reviewer accepts a Task, the system should confirm the workflow state or target record version has not changed since the evidence bundle was assembled, otherwise the action should be re-reviewed.