What FHIR is

In one line

FHIR (Fast Healthcare Interoperability Resources, "fire") is HL7's modern standard for exchanging health data. It breaks the record into bite-sized resources — Patient, Observation, Medication — that you read and write over an ordinary web (REST) API, in JSON.

The problem it solves

Before FHIR, exchanging health data meant either terse, cryptic HL7 v2 pipe-delimited messages or heavyweight CDA XML documents — powerful, but a steep wall for ordinary developers and a poor fit for mobile apps and web APIs. FHIR's insight was to meet developers where they already are: modern, web-native technology (JSON, REST, OAuth) so building a health integration feels like building any other API.

The four core ideas

• Resources — modular building blocks (~150 of them) for the things in healthcare: people, encounters, results, orders, medications, claims. Each is small and self-contained. Detail in resources, profiles & references.
• REST API — the same GET / POST / PUT / search verbs the whole web uses, so any developer can pick it up; no special middleware.
• References — resources link to each other (an Observation references its Patient), forming a connected graph rather than one giant document.
• Profiles — base resources are deliberately loose; a profile (US Core, India's NRCeS) constrains them for a real use case.

Resource maturity (FMM)

FHIR is honest about how settled each part is: every resource carries a FHIR Maturity Model level (0–5, plus Normative). Patient and Observation are highly mature and stable; newer resources may still change. When you build, check the maturity of the resources you depend on — it tells you how much churn to expect.

More than REST: the exchange paradigms

REST is the famous face, but FHIR supports several exchange patterns, and picking the right one matters:

Paradigm	Use it for
REST	apps reading/writing live data from a server
Documents	a signed, point-in-time snapshot (e.g. discharge summary)
Messages	event-driven exchange (an admit/transfer notification)
Bulk Data	exporting whole populations (NDJSON) for analytics

Profiles, IGs and conformance

Plain FHIR is intentionally generic — the same Patient everywhere. Real interoperability needs agreement on which fields are required, which value sets are bound, and which extensions apply. That agreement is packaged as an Implementation Guide (IG) containing profiles — e.g. US Core in the US, NRCeS profiles for India's ABDM. Conformance means conforming to the IG, not just "valid FHIR."

Why it won

• Developer accessibility — JSON/REST/OAuth lowered the barrier dramatically.
• The 80/20 design — cover the common 80% in the core, handle the rest with extensions.
• Regulatory tailwind — the US ONC mandates, India's ABDM, and others made FHIR the default for new work.
• An ecosystem — SMART on FHIR apps, CDS Hooks, and open servers (HAPI, Medplum) built on top.

Common pitfalls

• "Valid FHIR" ≠ "interoperable" — without a shared profile/IG, two systems can both be valid and still not understand each other.
• Ignoring maturity — building critically on a low-FMM resource invites breaking changes.
• Over-using extensions — every custom extension the other side doesn't know is a gap; prefer the standard element when one exists.
• Treating FHIR as a database — it's an exchange format; your storage model (openEHR, relational) is a separate decision.

Key takeaways

• FHIR = health data as small resources over a REST API, in JSON — web-native by design.
• Profiles/IGs turn generic FHIR into real interoperability; conform to the IG.
• It supports REST, documents, messaging and bulk — match the paradigm to the job.
• Practise it live in the FHIR Sandbox and Integration Engine labs.