A FHIR server is software that stores, manages, and exchanges healthcare data using a modern standard called FHIR (Fast Healthcare Interoperability Resources). It works like a specialized database with a built-in web API, allowing different healthcare applications to create, read, update, and delete medical records in a consistent, standardized format. If you’ve ever wondered how a patient’s lab results move from a hospital system to a mobile health app, a FHIR server is typically the technology making that possible.
How a FHIR Server Works
At its core, a FHIR server does two things: it stores healthcare data as standardized “resources,” and it exposes those resources through a RESTful API. REST is the same architectural style that powers most of the modern web, which means developers interact with a FHIR server using familiar HTTP requests rather than learning a proprietary healthcare protocol.
When an application needs a patient’s record, it sends a simple GET request to the server. When a clinic needs to file a new lab result, it sends a POST request. The server handles everything statelessly, meaning each request is independent and self-contained. This design makes FHIR servers easy to scale horizontally by adding more servers behind a load balancer, since no single server needs to remember what happened in a previous request.
The FHIR specification itself has four main layers: an information model that defines how resources are structured, constraints that enforce data validity, terminology that standardizes clinical codes and vocabularies, and usage rules that govern how everything behaves at runtime.
Resources: The Building Blocks
Everything in a FHIR server is organized around “resources,” which are standardized data objects representing distinct healthcare concepts. A Patient resource holds demographic information. An Observation resource captures a single clinical measurement like blood pressure or a glucose reading. An Encounter resource records an interaction between a patient and a provider, tracking details like whether the visit is planned, in progress, or completed.
There are over 150 resource types in the FHIR specification, but the standard was designed around an “80% rule.” Only elements that roughly 80% or more of systems would actually use are included in each resource’s base definition. If your organization needs to capture something unusual, you can extend a resource with additional fields rather than being stuck with an inflexible schema. This balance between standardization and flexibility is one of the reasons FHIR gained traction so quickly.
Resources don’t exist in isolation. An Encounter resource, for example, can reference over 40 other resource types including Conditions, Procedures, Observations, MedicationRequests, and DiagnosticReports. These references create a web of connected clinical data that applications can navigate programmatically.
API Interactions
A FHIR server supports a defined set of interactions organized at three levels. Not every server implements all of them. Each server publishes a Capability Statement declaring exactly which resource types and operations it supports.
At the instance level (working with a single record), the server supports reading a resource, reading a specific version of a resource, updating it, applying partial changes via a patch, deleting it, and retrieving its full change history. At the type level (working across all records of one kind), you can create new resources, search with filter criteria, and pull the history of all changes to that resource type. At the whole-system level, you can search across every resource type at once, retrieve system-wide change history, and execute batch or transaction bundles that perform multiple operations in a single call.
Search and Querying
Search is where FHIR servers get powerful. Rather than writing raw database queries, applications search using typed parameters that the server indexes automatically. The FHIR specification defines several parameter types: numbers, dates, strings (case-insensitive and accent-insensitive by default), tokens for coded values and identifiers, references to other resources, quantities with units, and URIs.
Two features make FHIR search particularly flexible. Chained parameters let you follow references across resources in a single query. For example, you could search for all Observations where the referenced Patient has a specific name, without needing to look up the patient ID first. You chain the parameters with a period, and the server resolves the path through the resource graph for you. Reverse chaining (using the _has parameter) works in the opposite direction, finding resources based on properties of other resources that point to them.
Composite parameters allow searching on pairs of values together, and a _filter parameter supports more complex search expressions with logical operators like AND and OR. Servers can also support full-text search across resource content and narrative text, with some implementing sophisticated text-indexing functionality similar to a search engine.
The Capability Statement
Every FHIR server is required to provide a Capability Statement on demand. This is a machine-readable document that tells any connecting application exactly what the server can do: which resource types it supports, which API interactions are available, and which data profiles it enforces. If a resource type or operation isn’t listed in the Capability Statement, it’s not supported.
This self-describing behavior is critical for interoperability. A new application connecting to your server doesn’t need a phone call or a PDF manual. It can query the Capability Statement endpoint and programmatically discover what’s available, then adapt its behavior accordingly. The statement also distinguishes between system-wide profiles (rules that apply to all instances of a resource) and use-case-specific profiles (rules that apply in particular workflows).
Security and Authorization
FHIR servers protect data using OAuth 2.0 for authorization and OpenID Connect for authenticating end users. The most widely adopted approach is the SMART App Launch framework, which layers healthcare-specific authorization logic on top of OAuth. It allows third-party apps to request access to specific patient data, with the server enforcing consent policies when issuing access tokens.
This model supports several workflows. In patient-facing scenarios, the OAuth server uses patient consent preferences as authorization policies when deciding what data an app can access. In system-to-system communication without a human in the loop, the OAuth 2.0 client credentials grant handles machine authentication, with some profiles supporting purpose-of-use declarations in the token request. For large-scale healthcare networks, additional frameworks exist to handle scalable registration and trust management across many organizations.
Why FHIR Replaced Older Standards
Before FHIR, healthcare data exchange relied heavily on HL7 v2, a messaging standard that has been in use for decades. V2 is reliable and widespread, but it has significant limitations. It lacks a formal information model, meaning the same message can be structured differently by different vendors. Optionality is everywhere in the standard, which leads to inconsistent implementations. And it has poor support for controlled vocabularies, making it harder to ensure that “blood glucose” means the same thing across two systems.
FHIR was designed to address these problems directly. It has a well-defined information model with structured resource definitions, uses web-native technologies that lower the barrier for developers, and supports controlled terminologies as a first-class feature. Because FHIR apps communicate through standardized APIs, they can be launched directly from within electronic health record systems, even when the app was built by a completely different vendor. The National Institute of Biomedical Imaging and Bioengineering notes that once a SMART on FHIR app is built, it can be deployed across many health systems without being rebuilt for each one.
U.S. Regulatory Requirements
FHIR servers aren’t just a technical preference in the United States. They’re increasingly a legal requirement. A 2020 CMS rule required Medicare Advantage organizations, state Medicaid and CHIP programs, and qualified health plan issuers on federal exchanges to implement a Patient Access API. This API lets patients use third-party health apps to access their claims, encounter data, cost-sharing information, and clinical results (including lab work) held by their payer.
A follow-up rule finalized in February 2024 expanded these requirements significantly. Payers must now implement Provider Access APIs (letting clinicians pull patient data from payers), Payer-to-Payer APIs (letting insurers exchange data when patients switch plans), and Prior Authorization APIs (handling approval requests electronically). These new APIs must be available by January 1, 2027, for most affected organizations. All of these mandated APIs are built on FHIR.
FHIR Versions and the Current Standard
FHIR has gone through several major releases, from DSTU2 through R4 and now R5. In the United States, FHIR R4 (specifically version 4.0.1) remains the regulatory baseline. The US Core Implementation Guide, which defines the minimum data requirements for U.S. healthcare systems, is built on FHIR 4.0.1. Some servers support multiple versions simultaneously, serving both legacy DSTU2 clients and modern R4 clients from the same system.
With each major version, the core data models evolve. The FHIR specification provides differential documents to help implementers navigate changes between versions, and when a change affects ONC certification requirements, it can be flagged for immediate implementation in certification tools.
Common FHIR Server Platforms
Organizations building FHIR infrastructure have several options. HAPI FHIR is the most widely adopted open-source implementation. Written in Java, it supports every FHIR version from DSTU2 through R5 and stores data using a JPA-based database layer. It provides a full RESTful API with flexible security configuration and is commonly used for both production systems and development testing.
Microsoft offers Azure Health Data Services, a managed cloud platform backed by an open-source FHIR Server for Azure project. This gives organizations the option of running Microsoft’s FHIR infrastructure in their own environment or using the fully managed cloud service. Medplum is another open-source option designed as an end-to-end FHIR-native platform, providing a complete backend with RESTful APIs and secure storage for teams that want to build healthcare applications from scratch on a FHIR foundation.