FHIR Is a Standard. EHR Implementations Are Not.

FHIR standardises the shape of healthcare data. It does not standardise what any given system chooses to put in it.

Most FHIR elements are optional. Most implementations support a subset of resources, a subset of search parameters, and read operations far more completely than write operations. Two systems can both be genuinely FHIR R4 conformant and still require materially different integration code.

“Supports FHIR” is the beginning of a technical conversation, not the end of one.

---

What is actually standardised

Worth being precise, because the standard does real work and dismissing it would be as wrong as overstating it.

FHIR R4 (v4.0.1) was released on 27 December 2018 and was the first version with normative content. Normative means the structure of core resources — Patient, Observation, Bundle and others — is locked, with HL7 committing to backward compatibility in subsequent releases.

That commitment is why R4 became the global baseline. Every major interoperability regulation currently references it: the ONC’s US Core Implementation Guide, the 21st Century Cures Act and CMS Interoperability and Patient Access rules in the United States, India’s ABDM implementation guide, and the profiles underpinning the European Health Data Space.

So a Patient resource has a defined structure everywhere. The RESTful interaction model is consistent. Resource identifiers, references and Bundle semantics behave the same way. That is genuine standardisation and it saves enormous effort.

The variance is not in the shape. It is in what fills it.

---

Where implementations diverge

Six categories, roughly in order of how much integration work each one costs.

1. Optionality

This is the single largest source of divergence and the least appreciated by teams new to FHIR.

Most elements in a FHIR resource are optional — cardinality 0..1 or 0..*. A conformant server may populate them, and may not. Two systems can both pass conformance testing while returning quite different amounts of information for the same patient.

“Must support” does not close this gap the way people expect. In an implementation guide, must-support means the system must be capable of populating an element — not that any given resource instance will contain it. A field can be must-support and absent, because the source data simply is not there.

The practical consequence: never assume an element exists because the specification defines it, or because a profile marks it must-support. Handle absence as a normal case in every mapping.

2. Profiles and implementation guides

Base FHIR is deliberately permissive. National and regional implementation guides constrain it into something interoperable, and which guide applies depends entirely on the market.

US Core is the most widely adopted profile set in the world. It has been based on FHIR R4 since version 3.0.0, and the current published version is 9.0.0, aligned with USCDI. A specific earlier version — 6.1.0 — remains relevant for certain ONC certification editions, which means a US-certified EHR’s conformance target depends on when it was certified.

Other markets have their own guides, and a product built to one does not automatically satisfy another. This is where “we support FHIR” most often conceals a substantial amount of work.

3. Version

R4 is not the only version in the wild, though it is overwhelmingly the dominant one.

R5 (v5.0.0) was released in March 2023 as a Standard for Trial Use, with breaking changes relative to R4. Major EHR vendors have not broadly adopted it, and no regulatory mandate references it. One FHIR server vendor reports that around 5% of its users have adopted R5.

Most notably, HL7’s US Realm Steering Committee decided in January 2024 that the next version US Core will be based on is R6 — skipping R5 entirely.

R6 entered its normative ballot process in January 2026, with publication expected in 2027 or later, targeting a fully normative core. US Core v10 is planned for R6.

R4B exists as a bridge release, backporting selected R5 features into R4 without requiring a full R5 commitment.

What this means practically: R4 remains the correct integration target for essentially all production work, and will stay valid for years after R6 publishes. But you should know which version a partner system runs, because it is a question with more than one answer.

4. Search parameter support

The specification defines many search parameters per resource. Implementations support a subset, and which subset varies.

A query that works against one server may return an error, an empty result, or an unfiltered result set against another. Chained searches, _include, _revinclude and composite parameters are supported inconsistently.

Always read the CapabilityStatement rather than assuming. It is the one authoritative source for what a specific server actually does, and it is routinely ignored.

5. Read versus write

Read support is common. Write support is not.

Many production FHIR APIs are read-mostly, with a narrower set of resources accepting POST or PUT, and additional constraints on what may be written and by whom. A workflow that assumes symmetric read and write capability across resources will discover the asymmetry late.

Write is also where the difficult problems concentrate — idempotency, reconciliation, conflict handling, and what happens when the same clinical fact arrives twice.

6. Terminology and extensions

Which code systems a system uses, at which versions, and how it handles codes it does not recognise all vary. SNOMED CT, ICD-10, LOINC and national dictionaries appear in different combinations by market.

Vendor-specific extensions are legitimate FHIR — the extension mechanism exists precisely so systems can carry data the base spec does not model. But an extension one system emits is meaningless to another unless both understand it.

What this means for architecture

The design conclusion follows directly: vendor-specific behaviour belongs in one place, not distributed through your application.

Application  →  EHR adapter  →  FHIR / HL7 interface  →  EHR

The adapter absorbs version differences, profile differences, search parameter availability, terminology mapping and extension handling. The application above it works with a normalised internal model.

Without that boundary, EHR-specific assumptions leak into business logic, and each new integration requires changes in many places rather than one. It also makes the integration untestable in isolation, because you cannot exercise the mapping without exercising the whole application.

Two further practices worth adopting early.

Treat the CapabilityStatement as an input, not documentation. Fetch it, parse it, and let it drive what your adapter attempts. A system that discovers unsupported operations at runtime handles a new partner better than one that assumes.

Write a conformance test per integration, not per standard. “Does this work with FHIR R4” is not a testable proposition. “Does this work against this server, at this version, with these profiles and these search parameters” is.

We cover where the wider system design decisions land in What Healthcare Architecture and Database Diagrams Need to Show.

---

How KH Scribe handles this

KH Scribe keeps FHIR integration behind a dedicated EHR adapter, so vendor-specific behaviour never reaches the clinical workflow. We target FHIR R4 — its normative core is stable and it remains the most widely deployed production baseline.

Each connection maps supported resources, search parameters, OAuth scopes, terminology and extensions into a versioned internal model. The adapter handles implementation-specific profiles, optional fields and write constraints; KH Scribe itself consumes vendor-neutral endpoints.

In practice that means preserving coded values and unknown extensions rather than discarding them, surfacing partial failures rather than degrading silently, retrieving detailed records only when they are needed, and validating every operation against the vendor’s documented contract and sandbox rather than assuming all R4 servers behave alike.

Adding a vendor — or eventually moving FHIR version — becomes adapter work rather than a change to clinical workflows.

---

Questions worth asking before you scope an integration

Nine, in the order that surfaces problems earliest.

• Which FHIR version? R4, R4B, or something else — and is it the same across all endpoints?
• Which implementation guide and which version of it? Conformance to a national guide is a different claim from base FHIR conformance.
• May we see the CapabilityStatement? Before scoping, not after.
• Which resources are supported for read, and which for write? These lists are usually different.
• Which search parameters are implemented? Including chained searches and _include if your workflow needs them.
• Which terminologies, at which versions? And what happens to unrecognised codes.
• Which extensions are emitted, and are they documented?
• What are the rate limits, pagination behaviour and bulk data options?
• How is authorisation handled? SMART scopes, token lifetimes, and what a launch context actually provides.

An integration partner who can answer these quickly is one who has done this before. One who cannot is not necessarily a poor partner — but the scoping estimate should reflect the discovery work that answering them will require.

---

Where this leaves FHIR

None of this is an argument against the standard. FHIR replaced a world in which every integration was bespoke from first principles, and the difference is substantial.

What it replaced that world with is one where the shape is agreed and the content is negotiated. That is a large improvement and it is not the same as plug-and-play.

The practical position: budget for FHIR integrations as though each partner system is a distinct piece of work sharing a common vocabulary with the others — because that is what they are. Teams that plan on that basis are rarely surprised. Teams that plan on “it supports FHIR, so it will just connect” almost always are.

---

Scoping an EHR integration?

FHIR scope depends on what the partner system actually supports. Importantly, you can identify most of this before development begins.

We map the FHIR version, implementation guide, CapabilityStatement, supported resources, search, write operations and terminology during scoping.

---

Frequently asked questions

Is FHIR a standard or not?

It is a genuine standard, and FHIR R4 contains normative content — meaning core resource structures are locked with a backward-compatibility commitment from HL7. What FHIR does not standardise is which optional elements a given system populates, which search parameters it supports, or whether it accepts writes.

Which FHIR version should we build against?

R4 (v4.0.1) for essentially all production work. It is the version referenced by US regulatory rules, India’s ABDM guide and the European Health Data Space profiles, and it will remain valid for years after R6 publishes.

Should we use FHIR R5?

Generally no. R5 was published in March 2023 as a Standard for Trial Use with breaking changes, has not been broadly adopted by major EHR vendors, and no regulatory mandate references it. HL7’s US Realm Steering Committee decided in January 2024 to base the next version of US Core on R6, skipping R5.

When is FHIR R6 coming?

R6 entered its normative ballot process in January 2026, with publication expected in 2027 or later and a fully normative core as the target. US Core v10 is planned for R6. R4 is expected to remain a valid implementation target well beyond that.

What is R4B?

A bridge release that backports selected R5 features into R4, allowing early adoption of specific capabilities without committing to a full R5 migration.

What is US Core and do we need it?

US Core is the most widely adopted FHIR profile set globally, based on R4 since version 3.0.0, with 9.0.0 currently published. It constrains base FHIR into something reliably interoperable for the US market and underpins ONC certification. If you are integrating with US-certified EHRs, it is the relevant conformance target — and note that which US Core version applies can depend on the certification edition.

Does “must support” mean an element will always be present?

No, and this is a common and costly misreading. Must support means a system must be capable of populating the element. A must-support element can legitimately be absent when the source data does not exist. Handle absence as a normal case.

Why does the same query work against one EHR and not another?

Because implementations support different subsets of search parameters. Chained searches, _include, _revinclude and composite parameters are particularly variable. The CapabilityStatement is the authoritative source for what a specific server supports.

Can we write data back to any EHR that supports FHIR?

Not reliably. Read support is far more common than write support, and where writing is available it is usually limited to a narrower set of resources with additional constraints. Confirm write capability per resource rather than assuming it follows from read capability.

What should we ask a partner system before scoping an integration?

Which FHIR version, which implementation guide and version, the CapabilityStatement, which resources support read versus write, which search parameters are implemented, which terminologies and versions, which extensions are emitted, rate limits and bulk options, and how authorisation works.

---

About the author

Nitin Sharma is a Backend Engineer at KastHunt Consulting LLP, working on AI-native healthcare software and real-time backend systems. His work focuses on Agentic AI, Node.js development, conversational AI, WhatsApp and SMS automation, and real-time AI systems, with an emphasis on building reliable and scalable healthcare technology.
He writes about backend engineering, healthcare technology, AI systems and the practical challenges involved in designing and deploying intelligent software products.

Questions or corrections: info@kasthunt.com

---

---