FHIR for AI: Healthcare Architecture Guide

FHIR and LLMs solve very different problems.

That is exactly why they work well together.

FHIR gives us a structured language for healthcare data exchange.

LLMs are very good at interpreting language, ambiguity and intent.

Put them together carefully and you can build systems that understand what a person is asking without making the model guess how the underlying healthcare data is organized.

What FHIR gives an AI system

HL7 describes FHIR as a standard for exchanging healthcare information electronically. Its basic building blocks are Resources: structured representations of things such as patients, observations, encounters, medications and appointments.

The official FHIR overview is worth reading because it makes one point particularly relevant to AI: machine processing works better when healthcare information is structured and standardized.

For an AI application, that structure can provide:

• explicit resource types;
• identifiers;
• timestamps;
• status;
• coded concepts;
• relationships between records;
• standardized search patterns;
• a known API surface in systems that implement it.

That is much better than telling a model:

“Here is 40 MB of JSON from an EHR. Good luck.”

FHIR is not a medical knowledge graph

FHIR tells you how healthcare information is represented and exchanged.

It does not automatically tell the AI what every relationship means for your workflow.

For example, FHIR may represent:

• the patient;
• an appointment;
• a practitioner;
• a condition;
• an observation.

But your application may still need to understand:

• which appointment statuses count as operationally active;
• which provider is allowed to perform a local service;
• whether a result supersedes another result;
• which payer rule applies;
• whether a clinic-specific workflow step has completed;
• what an event means inside your organization’s operations.

Standards reduce translation work.

They do not eliminate domain modeling.

Use FHIR as tools, not as prompt soup

One approach is to fetch a huge FHIR bundle and paste it into the model context.

Sometimes that works.

I usually prefer exposing deliberate tools.

For example:

• get_patient_demographics
• get_active_medications
• get_recent_observations
• get_upcoming_appointments
• search_encounters
• get_document_reference

Those tools may use FHIR underneath.

The agent reasons about the business task. The integration layer handles the exact FHIR queries, authorization and data transformation.

This makes the AI easier to test and keeps resource-access rules outside the model.

FHIR is especially useful for structured retrieval

In RAG in Healthcare, I argue that not every fact should be embedded as text.

FHIR is a good example.

If you need the latest potassium value, use the structured observation data.

If you need every narrative note discussing recurrent dizziness, semantic retrieval may be useful.

A hybrid system can use:

• FHIR search for structured facts;
• document retrieval for narrative content;
• terminology services for codes;
• LLM reasoning for synthesis.

That is often much more reliable than treating the entire record as documents.

Terminology still matters

FHIR resources can contain coded data using systems such as SNOMED CT, LOINC, ICD or local codes.

That helps enormously, but real implementations are messy.

You may encounter:

• local codes;
• incomplete coding;
• several code systems for similar concepts;
• free text next to structured codes;
• legacy mappings;
• different terminology by jurisdiction.

An AI system needs a strategy for terminology resolution rather than assuming every concept arrives perfectly normalized.

Version and implementation differences are real

“Supports FHIR” is approximately as specific as “has an API.”

FHIR has versions, profiles, implementation guides, extensions and varying levels of support across vendors.

One system may expose excellent read APIs but limited write operations.

Another may support a subset of resources.

Another may technically support FHIR while keeping the one workflow you need behind a proprietary endpoint.

So during discovery, check the actual implementation — not the marketing badge.

Authorization belongs around the API

FHIR does not mean the agent should see everything the FHIR server can return.

The application still needs:

• user/patient identity;
• tenant scope;
• role permissions;
• purpose-specific access;
• minimum-necessary thinking where applicable;
• audit logs;
• write permissions separate from read permissions.

The model should receive the data the workflow is allowed to use.

It should not become the authorization layer.

Write-back needs more discipline than read

Reading recent observations is one thing.

Creating or changing a resource is another.

For writes I want:

• schema validation;
• business-rule validation;
• correct references/identifiers;
• confirmation where appropriate;
• version/concurrency handling;
• explicit success/failure response;
• auditability.

A language model can decide that an appointment should be booked.

The application should decide whether the exact Appointment resource or vendor transaction is valid.

FHIR can improve provenance

One of the most useful properties of structured healthcare data is traceability.

If a generated summary says:

“HbA1c increased from 7.2% to 8.1%.”

we can preserve references to the exact Observation resources that support the statement.

That is useful for clinicians, testing and debugging.

It also discourages a bad habit in AI products: generating a beautiful clinical paragraph with no visible distinction between source facts and model synthesis.

But FHIR does not cover the whole healthcare business

This has been a recurring frustration in my own work.

Healthcare AI often needs more than clinical data.

It may need:

• CRM state;
• lead source;
• billing transactions;
• communication events;
• operational queues;
• staff actions;
• warehouse/inventory;
• payer workflows;
• custom administrative states.

FHIR covers a great deal, but no standard magically describes every operational event inside every healthcare organization.

That is why I think of FHIR as an excellent foundation, not the complete intelligence model.

The AI needs the clinical record and the operational story around it.

Where FHIR helps most

FHIR becomes particularly valuable when you want to build:

• chart-preparation assistants;
• clinical summarization;
• patient-facing agents that need bounded patient context;
• medication/lab review tools;
• care coordination workflows;
• EHR copilots;
• cross-system healthcare AI products;
• auditable retrieval systems.

It gives the integration layer a common vocabulary.

And every hour you do not spend reverse-engineering a proprietary patient JSON object is an hour you can spend on the actual product.

The principle

Do not make the model memorize your EHR schema.

Give it tools and context expressed in healthcare concepts it can reason about.

FHIR is one of the best standards we have for doing that.

But the complete production architecture still needs workflow semantics, permissions, transactions, evaluation and guardrails around it.