FHIR gets described as "the modern standard for healthcare data exchange" often enough that it's easy to nod along without knowing what actually happens when a client asks a FHIR server for data. It's simpler than most people expect, and understanding the flow is genuinely useful, whether you're evaluating a vendor's FHIR claims, scoping an integration, or hiring for one. Here's the technical flow in four steps, followed by a real request and response.
The technical flow, in four steps
Step 1. The client sends an HTTP request
An EHR, an app, or a patient portal sends a standard HTTP request to the FHIR server, for example, GET /Patient/12345 with an Accept: application/fhir+json header telling the server which format the client wants back.
Step 2. The FHIR server receives and validates the request
The server checks the resource type (Patient) and ID (12345) against its defined RESTful interactions, then retrieves the matching resource from its repository if it exists and the request is authorized.
Step 3. The FHIR resource is returned as structured data
The response comes back as a structured resource, in JSON or XML, the two formats FHIR supports natively, both defined in the core specification.
Step 4. The client consumes the response
The requesting application parses the structured data and uses it, displaying it, storing it, or feeding it into another workflow.
What that looks like in practice
Here's a minimal example of step 1 and step 3 above, a request for a single patient record, and the resource that comes back.
Every field has a defined meaning in the FHIR specification, resourceType tells you what kind of resource this is, id is the resource's unique identifier on this server, and the rest follows the structure HL7 defines for a Patient resource. That predictability is a big part of what makes FHIR easier to build against than a legacy message format with local, site-specific variations.
What makes FHIR powerful
RESTful APIs
FHIR's RESTful API uses the same HTTP verbs as any modern web API , GET to read, POST to create, PUT to update, DELETE to remove, so developers who already know REST are most of the way to knowing FHIR's interaction model.
OAuth 2.0 + SMART on FHIR
SMART on FHIR is HL7's implementation guide for authorizing apps against FHIR servers using OAuth 2.0, the same authorization pattern used across the rest of the web, adapted for clinical context and patient consent.
Native search
FHIR defines a standard search API with query parameters for filtering, sorting, and paging results, so clients can ask for exactly the resources they need instead of pulling everything and filtering client-side.
Profiles & Implementation Guides
Base FHIR resources are intentionally general. Profiles and implementation guides, like US Core, constrain and extend them for a specific country, use case, or regulatory requirement, without forking the underlying standard.
Read More: FHIR Integration Architecture Guide
How this compares to legacy HL7 v2
Unlike legacy HL7 v2 messaging, pipe-delimited segments, trigger events, and an interface engine translating between systems, FHIR uses modern web technologies most developers already know: REST, JSON, OAuth. That's a real part of why FHIR has been easier for new teams to pick up than v2 traditionally was. It's also why the two call for genuinely different engineering experience; we go deeper on that distinction, and what it means for hiring and project scoping, in HL7 v2 vs FHIR: Why "Do You Have HL7 Experience?" Is the Wrong Interview Question.
Better data, better decisions
The point of understanding the mechanics isn't the mechanics themselves, it's that a predictable, REST-based, well-documented API makes healthcare data more accessible, interoperable, and actionable, which is what actually improves decisions and outcomes downstream.
Read More: 10 FHIR Integration Architecture Mistakes
How Peerbits helps
Peerbits is a healthcare software engineering company that designs, builds, and integrates FHIR-based systems, from FHIR API implementation to SMART on FHIR app development and legacy-to-modern interoperability bridges.
- FHIR API design and implementation
- SMART on FHIR app development
- EHR integration
- HL7 v2-to-FHIR interoperability bridges
- Healthcare data mapping and validation
- Healthcare cloud modernization
- Dedicated healthcare engineering teams
Peerbits builds and integrates this software directly, working with engineers experienced in the specific FHIR use case a project requires, not a generic "interoperability" placement.
The takeaway
Underneath the acronym, FHIR is a fairly straightforward REST API pattern: a client makes an HTTP request, a server validates and retrieves a resource, and structured JSON or XML comes back. What makes it powerful isn't any single piece of that flow, it's that the whole pattern uses web technologies developers already know, layered with standard search, OAuth-based authorization, and profiles for real-world customization. Better data really does lead to better decisions, but only once the underlying mechanics are solid.
Building a FHIR integration?
Tell us what you're connecting to and what data needs to move, we'll help you scope the API design, authorization model, and profile requirements before you write a line of code.
Discuss Your FHIR IntegrationFrequently asked questions
A FHIR server acts as a resource repository and API gateway: it receives HTTP requests, validates the resource type and ID (or search parameters), retrieves or stores the matching resource, and returns it as structured JSON or XML.
No. FHIR supports both JSON and XML as native formats, the client specifies which one it wants using the Accept header, such as application/fhir+json or application/fhir+xml.
Most modern FHIR implementations use SMART on FHIR, an HL7 implementation guide built on OAuth 2.0, to authorize client applications and scope what data they can access, rather than FHIR defining its own custom authorization scheme.
Both. FHIR defines a standard search API with query parameters for filtering, sorting, and paging, in addition to the direct GET /[ResourceType]/[id] pattern for fetching a specific resource.
Base FHIR resources are deliberately general-purpose. Profiles and Implementation Guides constrain and extend them for a specific country, regulatory requirement, or use case, such as US Core, without changing the underlying FHIR standard itself.
Peerbits designs and builds FHIR APIs, SMART on FHIR apps, and interoperability bridges between legacy HL7 v2 systems and modern FHIR-based platforms, staffed by engineers with direct FHIR implementation experience.
