FHIR-RAG-MEDS Medical Decision Support
- FHIR-RAG-MEDS is a clinician-oriented decision-support system that integrates FHIR patient data with curated clinical guidelines for personalized recommendations.
- The architecture combines automated data retrieval, natural-language summarization, and LLM-driven guideline synthesis to enhance clinical decision-making.
- Evaluations in domains like hypertension and dementia show competitive performance, demonstrating feasibility for evidence-grounded clinical insights.
FHIR-RAG-MEDS is a clinician-oriented medical decision-support architecture that combines HL7 FHIR for patient-specific data access with retrieval-augmented generation over curated clinical guidelines. In its published form, the system retrieves recent patient data from a FHIR server, converts that data into a concise medical summary, retrieves guideline passages relevant to the query and summary, and uses a locally deployed LLM to generate personalized recommendations. The best-known implementation is framed as a practical prototype rather than a production-certified clinical system, and its empirical evidence comes from guideline-based evaluation rather than live patient deployment (Kabak et al., 9 Sep 2025).
1. Definition, purpose, and clinical scope
FHIR-RAG-MEDS was proposed to address two limitations of standalone medical LLMs: lack of access to current patient-specific EHR data and lack of grounding in validated, current, or local evidence-based guidelines. Its stated purpose is to improve personalized medical decision support by combining dynamic patient context from a FHIR server with retrieved guideline content. The system is positioned as clinician-facing support rather than autonomous decision-making, and its case study is the CAREPATH project, which focuses on older patients with multimorbidity, including mild cognitive impairment or mild dementia (Kabak et al., 9 Sep 2025).
The implemented scope is narrower than a general-purpose clinical AI agent. In the published prototype, patient context is assembled from demographics, medications, conditions, and observations retrieved from the FHIR server, then used to answer natural-language clinical questions such as pharmacological-treatment queries. The evaluated guideline domains are hypertension, COPD, sarcopenia, and dementia-related content labeled MCI/MD. This establishes FHIR-RAG-MEDS as a guideline-grounded, patient-contextualized recommendation system rather than a full longitudinal chart-review platform or autonomous diagnostic engine (Kabak et al., 9 Sep 2025).
A recurring misconception is that the system is simply a vector search interface over guideline text. In fact, its defining characteristic is the coupling of two retrieval spaces: structured patient-state retrieval through HL7 FHIR and unstructured evidence retrieval through a guideline vector store. The patient context is not merely appended raw; it is first transformed into a textual medical summary, which then participates in retrieval and generation (Kabak et al., 9 Sep 2025).
2. Core architecture and execution path
The architecture is divided into three components: preprocessing, data retrieval and query processing, and RAG execution. Operationally, the pipeline begins with guideline ingestion and patient-data retrieval, continues through FHIR Bundle construction and bundle summarization, and ends with retrieval of top guideline chunks and answer generation by a local Llama 3.1 8B model. The implemented server-side stack uses Python 3.12, LangChain, Chroma, Ollama, and an Angular front end integrated with SMART on FHIR and OAuth 2.0 (Kabak et al., 9 Sep 2025).
| Component | Implemented function | Main technologies |
|---|---|---|
| Preprocessing | Convert guideline documents to text, chunk, embed, and store | LangChain, Chroma, mxbai-embed-large |
| Query processing | Retrieve FHIR data, assemble Bundle, summarize patient context | HL7 FHIR, SMART on FHIR, Llama 3.1 8B |
| RAG execution | Retrieve top guideline chunks and generate response | Chroma, cosine similarity, Llama 3.1 8B |
The data path is explicit. Clinical documents such as PDFs are converted into text-based format, split into chunks, embedded, and stored in a vector database. In parallel, patient resources are retrieved from a FHIR server and assembled into a FHIR Bundle in FHIR JSON format. A prompt template then uses Llama 3.1 8B to convert the bundle into a concise textual summary. The clinician’s natural-language query is merged with this summary, embedded, and used to retrieve the most relevant guideline chunks. The retrieved chunks and the patient summary together form the context for the final recommendation (Kabak et al., 9 Sep 2025).
The user-facing workflow is mediated by an Angular application implementing SMART on FHIR integration. That front end authenticates users, retrieves patient data from compliant FHIR servers, and communicates with the FHIR-RAG-MEDS endpoints for recommendation generation. The paper presents this as a prototype path toward deployable, local-network clinical decision support rather than a completed enterprise workflow product (Kabak et al., 9 Sep 2025).
3. FHIR integration and patient-context construction
FHIR is used as the standardized interoperability layer. The published workflow describes retrieval through SMART on FHIR with OAuth 2.0, fetching relevant patient information from an HL7 FHIR server, then combining recent resources into a FHIR Bundle. The implemented system explicitly retrieves recent Condition, Medication, and Observation resources, alongside demographics, and uses those resources as the basis for its patient summary (Kabak et al., 9 Sep 2025).
A central design decision is the transformation from FHIR JSON into compact natural-language context. The bundle is not passed unchanged into the final answer-generation step. Instead, Llama 3.1 8B interprets the FHIR JSON and produces a medical summary in plain language. The stated rationale is to reduce technical jargon, maintain factual relevance, and avoid overwhelming the downstream model. This summary therefore functions as an intermediate representation between raw interoperable data and generative reasoning (Kabak et al., 9 Sep 2025).
The paper leaves several interoperability details unspecified. It does not define custom FHIR profiles, implementation guides, formal transformation rules, or exact REST endpoints and search parameters. It does not mention CDS Hooks, CQL, Questionnaire/QuestionnaireResponse, Bulk FHIR, or the FHIR Clinical Reasoning module. This limits reproducibility at the query-design level, but it also clarifies that the prototype’s contribution lies in end-to-end integration rather than in formal profile engineering (Kabak et al., 9 Sep 2025).
This design aligns with broader FHIR-native summarization work. EHRSummarizer, for example, describes a four-stage architecture—EHR Retrieval, Normalization & Structuring, Generative Summarization, and Presentation—in which targeted FHIR R4 resources are normalized into a stable “clinical context package,” generation is constrained to evidence present in that package, missing domains are indicated where feasible, and diagnostic or treatment recommendations are explicitly excluded (Kazemzadeh et al., 4 Jan 2026). FHIR-RAG-MEDS differs in being recommendation-oriented rather than summary-only, but both systems treat FHIR as the organizing abstraction and use an intermediate representation to mediate between raw healthcare resources and language generation.
4. Retrieval, grounding, and generation methodology
The guideline knowledge base is built from cleaned CAREPATH consolidated guideline documents. For the case study, the implemented subset covers hypertension, COPD, sarcopenia, and MCI/MD. Documents are converted to text, segmented with LangChain DirectoryLoader, RecursiveCharacterTextSplitter, and TextLoader, then embedded with Ollama’s mxbai-embed-large and stored in Chroma. The implemented chunk size is 1200 with overlap 100, and retrieval uses cosine similarity with top- guideline chunks (Kabak et al., 9 Sep 2025).
The retrieval query is itself composite. Before retrieval, the clinician query and the generated patient summary are merged and embedded together; after retrieval, the four guideline chunks and the patient summary are combined into the final generation context. This means patient data influences both which evidence is retrieved and how the final answer is synthesized. The paper does not describe keyword search, BM25, hybrid retrieval, metadata filtering, reranking, or explicit citation formatting in the current implementation (Kabak et al., 9 Sep 2025).
Grounding is therefore achieved by architectural context assembly rather than by explicit, statement-level citation. The paper emphasizes curated guideline retrieval as the main hallucination-mitigation mechanism, but also notes that stronger explainability through direct links to specific guideline sections remains future work. In that sense, the prototype is evidence-grounded but not yet provenance-rich at the output level (Kabak et al., 9 Sep 2025).
Related research clarifies why the summary layer is consequential. MedCase-Structured shows that frontier models perform consistently worse on structured FHIR bundle input than on equivalent plain-text case descriptions, with diagnostic-accuracy drops ranging from 4.21 to 23.16 percentage points across evaluated models and prompting settings. That result supports a model-friendly transformation step between canonical FHIR storage and final reasoning, rather than direct reliance on raw FHIR JSON alone (Muti et al., 28 May 2026).
5. Evaluation, reported performance, and evidential status
The published evaluation is based on approximately 70 clinician-authored question-answer pairs treated as ground truths. Questions were generated by a physician evaluation panel and ranged from simple factual prompts to more complex scenario-based questions. The comparison set includes BioMistral, Llama 3.1 8B, Meditron, and OpenBioLLM, while FHIR-RAG-MEDS is additionally evaluated with RAGAS and human physician review (Kabak et al., 9 Sep 2025).
| Domain | Physician average | Faithfulness | BERTScore F1 |
|---|---|---|---|
| Dementia | 3.67 | 0.481 | 0.6372 |
| COPD | 4.38 | 0.725 | 0.6325 |
| Hypertension | 4.45 | 0.599 | 0.6503 |
| Sarcopenia | 4.36 | 1.0 | 0.7367 |
Across the four evaluated domains, FHIR-RAG-MEDS achieved the strongest reported scores among the compared systems on the listed automated metrics. For dementia, it obtained Prometheus 2 average 4.0000, BERTScore F1 0.6372, ROUGE-L F1 0.25427, and METEOR 0.37810. For COPD, the corresponding values were 4.3846, 0.6325, 0.25853, and 0.36496. For hypertension, they were 4.45, 0.6503, 0.299, and 0.463. For sarcopenia, they were 4.36, 0.7367, 0.465, and 0.640 (Kabak et al., 9 Sep 2025).
The RAGAS results are more mixed and are particularly important for interpretation. Answer Correctness ranged from 0.783 in dementia to 0.953 in hypertension. Answer Relevancy ranged from 0.670 in COPD to 0.840 in sarcopenia. Context Precision was near-perfect or perfect in all four domains, while Faithfulness varied substantially: 0.481 for dementia, 0.725 for COPD, 0.599 for hypertension, and 1.0 for sarcopenia. The reported human evaluation involved three independent physicians using a 5-point Likert scale, yielding domain means of 3.67 for dementia, 4.38 for COPD, 4.45 for hypertension, and 4.36 for sarcopenia, with Cohen’s and correlation between automated and physician scores . The paper also reports that 12% of responses were judged to lack specific actionable insights (Kabak et al., 9 Sep 2025).
The evidential status of these results is limited by design. The study explicitly states that it did not involve real patient data. It evaluates a prototype against guideline-derived questions and expert review rather than live workflows, controlled clinical outcomes, or prospective deployment. The reported gains therefore establish feasibility and comparative answer quality in a constrained benchmark setting, not effectiveness or safety in routine care (Kabak et al., 9 Sep 2025).
6. Position within the FHIR-RAG research landscape
FHIR-RAG-MEDS belongs to a broader class of systems that treat FHIR as the canonical patient-data substrate and combine it with retrieval or precomputation layers to support downstream reasoning. “Semantic Enrichment of Streaming Healthcare Data” describes an earlier precursor pattern in which heterogeneous streaming inputs are normalized into FHIR, serialized as RDF, stored in Apache Jena TDB, and queried with SPARQL. That work is especially relevant as a structured retrieval backbone, showing how patient, encounter, and observation data can be fused into a semantically queryable substrate before application-layer inference or analytics (Cotter et al., 2019).
Other research extends the ingestion side. Infherno targets end-to-end synthesis of FHIR R4 resources from free-form clinical notes using an agentic loop with code execution and fhir.resources, restricted in its experiments to Patient, Condition, and MedicationStatement. Its contribution is strongest as a note-to-FHIR preprocessing layer that could populate the structured patient context later consumed by retrieval and decision-support systems (Frei et al., 16 Jul 2025). Semi-autonomous conversion from proprietary EHR schemas to FHIR likewise addresses the upstream normalization problem, using weighted lexical, morphological, and semantic similarity to map vendor-specific elements into connected FHIR resources suitable for SMART-on-FHIR exposure (Chapman et al., 2019).
The literature also highlights limits of naïve FHIR reasoning. Reinforcement-learning work on tool-calling agents over FHIR frames question answering as sequential decision-making over a typed graph of resources and reports an improvement in answer correctness from 50% for o4-mini to 77% on FHIR-AgentBench using a smaller Qwen3-8B model, underscoring that clinically meaningful FHIR reasoning often requires multi-step traversal, filtering, and aggregation rather than single-shot prompting (Knorr et al., 13 May 2026). For longitudinal settings, VISTA Architect goes further by replacing repeated raw-record retrieval with a persistent provenance-linked graph and a clinically abstracted timeline layer, achieving 96.4% accuracy on 15 tumor-board-salient variables across 1,180 thoracic oncology patients and outperforming a matched BM25 RAG baseline (Kiiskinen et al., 21 Jun 2026). These systems suggest that FHIR-RAG-MEDS occupies one point in a larger design space that includes graph-backed temporal memory, tool-augmented traversal, and precomputed patient-state abstractions.
7. Limitations, risks, and future directions
The immediate limitations of FHIR-RAG-MEDS are explicit. The prototype was not tested on real patient data, does not report workflow studies or patient outcomes, and shows imperfect faithfulness in some domains, especially dementia and hypertension. The current implementation also lacks explicit section-level citation or claim-to-guideline traceability in the generated output, even though improved explainability through direct links to guideline sections is identified as future work (Kabak et al., 9 Sep 2025).
A broader limitation is that FHIR access does not itself solve context quality. EHRSummarizer emphasizes data minimization, stateless processing, trust-boundary-aware deployment, omission of unsupported sections, and avoidance of diagnostic or treatment directives, illustrating a more conservative safety posture for FHIR-grounded generation over clinical records (Kazemzadeh et al., 4 Jan 2026). FHIR-RAG-MEDS does not yet provide that degree of evidence-bounded output control or explicit omission-aware UI behavior.
The research landscape also exposes technical risks that become salient as the architecture broadens. If multimodal evidence such as ImagingStudy, DiagnosticReport, or document attachments were added to the retrieval corpus, MedThreatRAG shows that multimodal RAG systems are vulnerable to poisoning, especially through Cross-Modal Conflict Injection, which can reduce answer F1 by up to 27.66% and drive clinically plausible but false grounding (Zuo et al., 24 Aug 2025). If the system evolves toward multi-agent querying and write-back actions over live FHIR servers, concurrency and stale-read risks studied through the FHIR Resource Access Graph become relevant, including Simultaneous Write Conflict, TOCTOU Authorization Violation, and Cascading Update Race (Mohammed et al., 3 Apr 2026).
Future work proposed in the FHIR-RAG-MEDS paper includes improving accuracy and clinical relevance, continual incorporation of updated medical research and guidelines, more robust human-in-the-loop feedback, reinforcement learning with human feedback, and better explainability. A plausible implication is that later versions may converge toward a hybrid architecture: FHIR as canonical patient-state access, precomputed or summarized context to compensate for raw-FHIR reasoning difficulty, curated guideline retrieval for evidence grounding, and stronger provenance, auditing, and safety controls across the retrieval-generation path (Kabak et al., 9 Sep 2025).
