FHIR-GRAMS: Graph-Normalized Records and a Multi-Agent System for EHR Question Answering

FHIR-GRAMS pipeline: hierarchical FHIR normalization, planner routing, specialist field selection, and a composer with retrieved skills and atomic tools in a plan-and-execute loop. — FHIR-GRAMS first normalizes the FHIR graph into canonical clinical views, then a planner routes the question to resource-specific specialists that keep only the relevant fields, and a composer answers with retrieved skills and deterministic atomic tools.

+11.6 / +8.0

judged-accuracy points over the best baseline (two Gemini backbones)

100% / 96.7%

on MedAgentBench v1 / v2 (Gemini-3.1-Flash-Lite)

up to 2.1×

fewer tokens per query than GRASP

4 / 4

benchmarks with the best exact match

Abstract

Answering clinical questions over Fast Healthcare Interoperability Resources (FHIR) records requires assembling evidence that is scattered across reference-linked resources and buried in deeply nested attributes. Existing agents give these raw resources to a single model, which must retrieve, relate, and compute within one long context. We present FHIR-GRAMS, a multi-agent framework that first normalizes the FHIR graph into canonical clinical views and then divides the reasoning: a planner routes the query to resource-specific specialists that select the relevant fields, and a composer answers from the aggregated evidence with retrieved skills and deterministic tools. On four FHIR question-answering benchmarks, FHIR-GRAMS improves accuracy over the strongest baseline by 11.6 and 8.0 points with two Gemini backbones, while using fewer tokens and less time per query.

Approach

A patient's FHIR record is a graph of typed, nested JSON resources linked by references. A single clinical event is often split across resources: a prescription may carry no drug name and only point to a separate Medication resource, while the dispense record spells the same drug differently. FHIR-GRAMS separates evidence processing from answer composition.

Hierarchical FHIR graph normalization

Every resource is flattened into path–value pairs, and a hand-written map assigns each path a canonical field name. Resources that belong to one clinical entity are then merged into a single canonical view: a medication request, the Medication it references, and its dispenses and administrations become one flat medication view. Every entry keeps the resource it came from, so the agents read compact, consistently named fields while each value stays traceable to the record. Views are computed once per patient and form a layer above the original resource graph.

Normalizing one prescription from the worked example. Three resources store the drug name under three paths and spellings; κ sends all of them to medication.name, and the view keeps each value tagged with its source. The request's reference is followed to reach the Medication resource.

Planner

Reads only the question and selects the view types it involves, guided by a routing skill, so the decision does not grow with the size of the record.

Specialists

One agent per view type keeps only the canonical fields the question needs; metadata and raw codes are hidden by a fixed exclude list.

Composer

Retrieves the top-K procedure skills (temporal reasoning, code matching, cross-resource integration) and plans chains of 13 deterministic atomic tools in a plan-and-execute loop for up to N rounds.

Worked Example

How FHIR-GRAMS answers the question from the overview figure. The record is normalized once; the planner, specialists, and composer then each do one small job, and the answer is computed by deterministic tools rather than written from memory. Press play, or step through.

Press Play to run the example.

Question

“”

Record

4 medication views metforminglipizidelisinoprilinsulin glargine 3 observation viewsHbA1cHbA1cHbA1c

Normalized once, before any question: each prescription with its Medication, dispenses, and administrations becomes one flat medication view; each lab result becomes an observation view with obs.name, obs.value, obs.unit, obs.time.

Planner

Routing plan Medication Observation Condition not invoked

Reads only the question. Its routing skill maps drugs, prescriptions to medication views and labs, measurements to observation views, so two specialists run and the record's size never enters this decision.

Specialists

Medication specialist · 4 views

medication.namerequest.authoredOnrequest.status request.dosedispense.quantity

taking depends on the order's status, before on its date; dose fields are not asked for.

Observation specialist · 3 views

obs.nameobs.valueobs.unitobs.time

Everything a latest value question needs, nothing else.

keptnot selected

Evidence: the selected entries of 7 views, each tagged with its source resource.

Composer

Retrieved skills (K = 3) temporal reasoning code matching cross-resource integration

plan     1  
         2  
execute  1  → metformin, glipizide, lisinopril   insulin glargine was ordered after the cutoff
         2  → 6.9 % on 2024-03-15   the latest of the three HbA1c values
reason      code-matching skill: metformin and glipizide are antidiabetic agents;
      lisinopril is an antihypertensive → dropped. No further round needed.
answer      final_answer(…)

13 deterministic atomic tools + final_answer — the calls used light up

get_resourcesfilter_by_datefilter_by_valueget_by_indexextract_field_valuesort_recordsfind_extremeaggregatecount_valuescompare_valuescalculate_differencecalculate_time_offsetcombine_evidencefinal_answer

Answer

“metformin and glipizide; the latest HbA1c is 6.9% (2024-03-15).”

One round, two tool calls. Every number in the answer came out of a deterministic tool, so it can be checked against the evidence.

Illustrative patient record and simplified tool-call syntax, following the worked example in the paper's appendix.

Results

We evaluate on the test sets of four FHIR question-answering benchmarks: FHIR-AgentBench and FHIRPath-QA (built on MIMIC-IV-FHIR) and MedAgentBench v1 and v2 (built on Stanford STARR records), writing all skills from only 20 FHIR-AgentBench training queries. Each cell is exact match / LLM-judged accuracy (%). FHIR-GRAMS is the most accurate method with both backbones and has the best exact match on every benchmark; with Gemini-2.5-Flash it already matches the best baseline running on the newer Gemini-3.1-Flash-Lite.

Method	Backbone	Per-benchmark accuracy (EM / Judge, %)				Overall
Method	Backbone	FHIR-AgentBench (409)	FHIRPath-QA (222)	MedAgentBench v1 (40)	MedAgentBench v2 (120)	EM ↑	Judge ↑	Latency (s) ↓	Tokens (k) ↓
FHIRPath-QA^†	GPT-4.1-Mini	–	– / 41.5	–	–	–	41.5	–	–
FHIR-Hopper^†	Gemini-3-Flash	– / 56.8	–	– / 95.9	–	–	58.7	–	23.1
FHIR-Hopper^†	Claude Sonnet 4.6	– / 61.1	–	– / 94.6	–	–	62.7	–	21.0
CodeAct, single-turn	Gemini-2.5-Flash	28.4 / 30.6	36.0 / 38.7	42.0 / 44.0	44.7 / 45.3	33.7	35.8	6.36	6.1
CodeAct, multi-turn		49.9 / 53.5	41.9 / 45.9	65.0 / 70.0	67.3 / 68.7	51.0	54.5	15.25	27.6
GRASP		51.3 / 57.5	32.4 / 35.6	52.0 / 72.5	54.2 / 75.8	46.4	54.9	12.13	45.8
FHIR-GRAMS (ours)		58.7 / 66.7	57.2 / 62.6	72.5 / 72.5	70.0 / 70.8	60.7	66.5	11.62	26.1
CodeAct, single-turn	Gemini-3.1-Flash-Lite	19.1 / 23.0	23.4 / 27.9	65.0 / 65.0	65.0 / 66.7	29.6	33.1	7.66	5.9
CodeAct, multi-turn		53.9 / 60.3	58.1 / 63.5	80.0 / 82.5	85.8 / 86.7	61.2	66.3	18.04	41.6
GRASP		53.1 / 60.3	46.4 / 49.1	72.5 / 95.0	64.2 / 72.5	53.9	60.8	20.46	56.8
FHIR-GRAMS (ours)		56.2 / 65.5	68.0 / 73.9	100.0 / 100.0	96.7 / 96.7	67.9	74.3	12.07	26.6

Best per backbone in bold. ^†Reported by the FHIRPath-QA and FHIR-Hopper papers with other backbones; not directly comparable. Single-turn CodeAct is cheapest but trails by 27–41 accuracy points.

Efficiency

FHIR-GRAMS needs about 12 s and 26k tokens per query with either backbone, less than multi-turn CodeAct (15–18 s, 28k–42k tokens) and GRASP (12–20 s, 46k–57k tokens), because the specialists bound the evidence that reaches the composer. Among reported systems, FHIR-Hopper uses a similar number of tokens (21k–23k) but is less accurate on FHIR-AgentBench (56.8–61.1 vs. 65.5–66.7 judged).

Ablations

On FHIR-AgentBench with Gemini-2.5-Flash, adding the planner and then the specialists to a composer that reads the full normalized record raises judged accuracy by 8.8 points at almost half the tokens (57.9 → 66.7, 51.8k → 28.3k). Replacing raw resources with canonical views alone improves accuracy from 48.1 / 56.4 to 52.3 / 61.1 while lowering tokens. In skills, success and failure indicators help, whereas worked examples hurt and cost about 3.8k more tokens.

Ablation bars for components, graph normalization, and composer-skill content with token costs. — Ablations with tokens per query on the right axis (accuracy axis is cropped).

K-N sweep: accuracy, tokens per query, and retrieval F1. — Varying retrieved skills K and composer rounds N: (a) accuracy, (b) tokens per query, (c) retrieval F1 against gold resources. Skills and rounds add up in accuracy (+14.6 judged points together) while their token costs compound.

What's Next: FHIR-R1

FHIR-GRAMS reaches its accuracy with hand-written skills and frozen API models. In ongoing work, FHIR-R1, we move from agent design to agent training: a multi-turn tool-using Qwen3-8B agent over patient FHIR records is post-trained with reinforcement learning (DAPO). A teacher that receives privileged information is trained first and then distilled into a deployable student, which sees only the question and the record, through on-policy self-distillation.

BibTeX

@misc{ge2026fhirgrams,
  title  = {FHIR-GRAMS: Graph-Normalized Records and a Multi-Agent System for EHR Question Answering},
  author = {Ge, Xueren and Asgari Mehrabadi, Milad and Kuang, Jilong},
  year   = {2026},
  note   = {Under review}
}