Ask anyone building in digital health what standard they are working with, and the answer is almost always FHIR.

A Beginner's Guide to HL7 FHIR

Ask anyone building in digital health what standard they are working with, and the answer is almost always FHIR. Fast Healthcare Interoperability Resources has become the lingua franca of health data exchange — the specification behind patient portals, app integrations, national health records programmes, and the APIs mandated by regulators in the United States and beyond.

Yet FHIR is frequently misunderstood. It is not a database, not a messaging protocol in the traditional sense, and not a single product you install. It is a specification: a set of rules describing how healthcare information should be structured, exchanged, and queried. This guide explains what FHIR is, how it works, and what beginners need to know before building with it.

Why Interoperability Needed a New Standard

Healthcare data has historically been trapped in silos. A hospital's electronic health record (EHR) could not readily share information with a neighbouring clinic's system, a laboratory, or a patient's own app. Earlier standards attempted to solve this. HL7 version 2, introduced in the late 1980s, became ubiquitous for messaging between systems but relied on pipe-delimited segments that varied in implementation from site to site. HL7 version 3 and the Clinical Document Architecture (CDA) offered greater rigour but proved complex to implement.

FHIR, first published by HL7 in draft form in 2014, took a different approach. It borrowed the modern web's idioms — RESTful APIs, JSON and XML representations, predictable URLs — and applied them to clinical data. The result is a specification that web developers can learn far more quickly than its predecessors.

The Core Concept: Resources

Everything in FHIR is built from resources. A resource is a modular, reusable unit representing a discrete clinical or administrative concept. Rather than one monolithic patient record, FHIR decomposes healthcare data into many small pieces that reference one another.

Common resource types include:

  • Patient — demographics and administrative identity
  • Practitioner — clinicians and other care providers
  • Encounter — a clinical interaction between patient and provider
  • Observation — measurements and findings, such as blood pressure, lab values, or vital signs
  • Condition — diagnoses and problems
  • MedicationRequest — prescriptions
  • DiagnosticReport — results of investigations, often grouping Observations
  • Immunization — vaccination records
  • AllergyIntolerance — recorded allergies
  • CarePlan — planned care activities

Because resources are independent and reference each other by identifier, the same Observation can be reused across a lab report, a clinical dashboard, and a patient-facing app without duplication.

How FHIR Exchange Works

FHIR defines several paradigms for exchanging data. Understanding which one applies to your use case is essential.

RESTful API. The most common approach. A FHIR server exposes resources at predictable URLs, and clients interact using standard HTTP verbs. Reading a patient looks like a GET request to a Patient endpoint; creating one is a POST; updating is a PUT. This is the paradigm most developers encounter first.

Search. FHIR specifies a rich search mechanism with defined parameters. Clients can query for observations by patient, date range, code, or status. Search results are returned as a Bundle — a container resource that holds a collection of other resources along with pagination links.

Documents. FHIR can bundle resources into a document with a Composition resource acting as a header, suitable for discharge summaries or referral letters.

Messaging. For event-driven workflows, FHIR supports message Bundles triggered by specific events.

Subscriptions. Servers can notify clients when resources change, enabling real-time applications such as alerting a care team when a monitored value crosses a threshold.

Profiles and Implementation Guides

Base FHIR is deliberately flexible, which creates a problem: two systems can both be "FHIR compliant" yet disagree on which fields are mandatory, which terminologies are used, and which extensions apply.

This is solved through profiling. A profile constrains a base resource — tightening cardinalities, binding elements to specific value sets, and adding extensions. Profiles are published in Implementation Guides (IGs), which define how FHIR is used for a particular purpose, jurisdiction, or specialty.

For beginners, the practical implication is important: you rarely implement base FHIR in isolation. You implement a specific IG. Notable examples include the US Core Implementation Guide, which defines the minimum conformance expectations for US interoperability, and national programmes in other jurisdictions that publish their own profiles.

Terminologies: Codes That Mean Something

FHIR relies on coded values rather than free text wherever possible, drawing on established terminology systems. The most frequently encountered include:

  • LOINC — laboratory observations and clinical measurements
  • SNOMED CT — clinical findings, procedures, and diagnoses
  • ICD-10 — disease classification for billing and statistics
  • RxNorm — medications
  • UCUM — units of measure

Correct terminology binding is one of the most common sources of implementation friction. A blood pressure reading expressed with the wrong LOINC code will not interoperate, even if every other element is perfect.

Regulatory Momentum

FHIR's rise has been accelerated by regulation rather than purely by market preference. In the United States, the 21st Century Cures Act directed the Office of the National Coordinator for Health IT to promote interoperability, and subsequent rules require certified health IT to expose FHIR-based APIs conforming to specified implementation guides. Related provisions address information blocking — practices that unreasonably interfere with access, exchange, or use of electronic health information.

Internationally, FHIR underpins national programmes in a number of countries and is used by large-scale research initiatives. The specification is also widely adopted in payer, public health, and clinical research contexts.

Getting Started: A Practical Path

For developers approaching FHIR for the first time, a staged approach works well.

Read the specification, not just tutorials. The FHIR specification is published online and is unusually readable for a standards document. Start with the resource list and the RESTful API page.

Experiment with a public sandbox. Several publicly available FHIR test servers allow you to query synthetic patient data without any setup. Practising search parameters and reading Bundles builds intuition quickly.

Pick a target IG early. Decide which implementation guide governs your use case before designing your data model. Retrofitting conformance later is expensive.

Model your data as resources first. Resist the temptation to design a relational schema and map to FHIR afterwards. Think in resources and references from the beginning.

Validate constantly. FHIR publishes formal validation tooling that checks instances against profiles. Running validation in continuous integration catches conformance errors before they reach a partner system.

Expect terminology work. Budget time for mapping local codes to LOINC, SNOMED CT, and RxNorm. This is frequently underestimated.

Common Beginner Mistakes

Several pitfalls recur. Treating FHIR as a database rather than an exchange specification leads to poor architectural choices. Ignoring version differences causes integration failures, since implementations may target different releases. Assuming that "supports FHIR" guarantees compatibility overlooks the role of profiles and IGs. And neglecting patient identity management — the problem of reliably matching records across systems — creates downstream safety risks that no amount of specification compliance resolves.

Conclusion

FHIR has earned its position as the default standard for health data exchange because it aligns clinical data modelling with the conventions of modern web development. For newcomers, the learning curve is real but manageable: master resources, understand the exchange paradigms, choose the right implementation guide, and respect terminology. Do those four things, and the specification stops feeling like bureaucracy and starts feeling like the pragmatic toolkit it was designed to be.

Frequently Asked Questions

Q: What does FHIR stand for? A: Fast Healthcare Interoperability Resources. It is a specification published by HL7 describing how healthcare information can be structured and exchanged between systems.

Q: Is FHIR a database or a programming language? A: Neither. FHIR is an exchange specification. It describes data structures and API behaviour, leaving storage implementation to the vendor or developer.

Q: What is the difference between HL7 v2 and FHIR? A: HL7 v2 is a messaging standard using delimited text segments, widely deployed but inconsistently implemented. FHIR uses modern web APIs, JSON or XML representations, and modular resources, making it easier for contemporary developers to adopt.

Q: What is a FHIR resource? A: A resource is a modular unit of clinical or administrative data — such as Patient, Observation, or MedicationRequest — that can be exchanged independently and referenced by other resources.

Q: What is a FHIR profile? A: A profile constrains a base resource for a specific use case, defining mandatory elements, permitted values, and extensions. Profiles are published collectively in Implementation Guides.

Q: Do I need to use FHIR to build a health app? A: Not necessarily, but if you intend to connect to EHR systems or participate in regulated interoperability programmes, FHIR is usually the expected interface.

Q: Where should a beginner start learning FHIR? A: Begin with the official FHIR specification's resource list and RESTful API documentation, then practise against a public test server before committing to a specific implementation guide.

Disclaimer: This article is for informational purposes only and does not constitute technical, legal, or regulatory advice. Specification versions and regulatory requirements change; verify against current HL7 publications and applicable national rules.

Sources:

Featured

Follow us

Authors

Tags