FHIR (Fast Healthcare Interoperability Resources)

FHIR (Fast Healthcare Interoperability Resources) is a standard for exchanging healthcare data, published by HL7 International 1. It splits clinical information into defined units called resources, such as Patient, Observation, or MedicationRequest, that software can read and write through a web API 1.

Why does FHIR matter for clinical AI?

An AI tool is only as useful as the data it can reach and the place it can write back. FHIR standardizes that plumbing, and US regulation made it the default. ONC's 2020 Cures Act final rule required certified health IT to offer a standardized API for patient and population services built on FHIR 3. CMS's 2024 Interoperability and Prior Authorization final rule requires impacted payers, including Medicare Advantage and Medicaid plans, to run FHIR APIs, among them one for prior authorization, with most API deadlines on January 1, 2027 4. That rule is the backdrop for the prior-authorization agents now being built.

How does FHIR work in practice?

Each resource has a defined structure, and a system requests or sends resources with standard web calls 1. SMART on FHIR adds the app layer. It began in 2010 at Harvard Medical School and Boston Children's Hospital with the goal of apps that are written once and run unmodified across different health IT systems, and it adopted FHIR's data models and API in 2013 2.

For AI, FHIR shows up in two places.

As model input. A Google-led team represented patients' entire raw records in FHIR format: 216,221 adult inpatients at two US academic medical centers, unrolled into 46,864,534,945 data points. Deep learning models trained on that representation predicted in-hospital mortality with an AUROC of 0.93 to 0.94 across sites, without site-specific data harmonization 5.

As the connection. Agents and LLM tools increasingly read charts through FHIR calls, sometimes wrapped by newer layers such as the Model Context Protocol. The evidence on how well that works is collected in EHR-integrated agents.

Common misunderstandings

FHIR access means an AI tool can write to the chart. The certified API the Cures Act rule required covers read access for patient and population services 3. Writing orders or notes back is a separate integration question.

The base standard is enough. The SMART team found early on that real deployments needed "commonly accepted pragmatic constraints on the base FHIR specification" 2. Implementation guides do that work for specific uses, such as prior authorization.

FHIR makes data clean. It standardizes structure and exchange. Whether a field is filled in, coded consistently, or current still depends on the source system. A model that works on one site's FHIR data still needs external validation on yours.

What to ask a vendor

• Which FHIR resources does the tool read, and which does it write?
• Does it use our EHR's certified FHIR API, or a proprietary interface or database extract?
• Does it support SMART on FHIR launch and authorization, and what scopes does it request?
• What happens when a resource is missing or coded differently at our site? Has it been tested on our data?
• If it acts on the record, where does a clinical decision support recommendation stop and an automated action begin?

Related terms

• Model Context Protocol in health IT: a newer connection layer that often sits on top of FHIR.
• Agentic AI: systems that read and act through these interfaces.
• MCP and interoperability for hospital agents: how the standards fit together.