Healthcare interoperability: what FHIR does and does not standardise

The Promise and Reality of Modern Healthcare Interoperability

Healthcare organisations exchange information across systems with different data models, local practices and supported interfaces. The introduction of HL7 Fast Healthcare Interoperability Resources (FHIR) transformed health technology by establishing a modern, web-standard framework based on modular resources [S1]. By breaking complex medical records into discrete, addressable components like patients, observations, and medication requests, FHIR provides building blocks for applications exchanging clinical information; latency and supported operations remain implementation-dependent. However, a procurement risk is assuming that adopting FHIR provides universal data compatibility. In practice, FHIR standardizes the syntax, structure, and transport of clinical objects, but it does not automatically harmonize institutional workflows, clinical intent, or complex state logic. Understanding the precise boundary between what FHIR standardizes and what requires custom implementation guides is essential for health IT leaders evaluating software integration vendors and architectural strategies [S1]. This analysis uses the FHIR R5/v5.0.0 pages checked on 22 October 2026. A buyer should record the target release and implementation guide before comparing interfaces. The overview describes scope; it does not attest to a particular vendor installation, current connector coverage or achieved service performance [S1].

Core Architecture: Resources, Web Standards, and APIs

At its core, FHIR operates much like modern consumer web applications, utilizing familiar internet technologies to streamline data exchange [S1]. Clinical information is modularized into discrete resources comparable to digital building blocks. A patient resource holds demographic details, an observation resource records vital signs or lab results, and a medication request captures prescription orders [S2]. FHIR defines a RESTful exchange approach using HTTP interactions, alongside other exchange patterns. Which operations a server supports must be checked rather than assumed. FHIR is not a security protocol; deployments require appropriate external security mechanisms, and SMART may be relevant for an application-access design [S1, S3]. Familiar web standards can reduce the amount of unfamiliar interface machinery, while clinical semantics and local implementation choices still need specialist review. Yet, while underlying plumbing is standardized, semantic richness required for complex clinical decision support often demands additional domain-specific agreements [S1]. A useful procurement question is whether the documented resource and operation are supported in the actual configured server, with the necessary profile, permissions and error handling. A generic software capability statement, an instance description and a requirements statement serve different purposes and should not be treated as interchangeable proof [S6].

What FHIR Standardises: Syntax, Structure, and Transport

To evaluate interoperability claims accurately, technology leaders must recognize precisely what the FHIR specification governs. FHIR provides definitive data models for core clinical entities, establishing exact data types, cardinality rules, and naming conventions for elements within resources such as conditions, allergies, and encounters [S2]. It defines RESTful interactions for querying and changing resources, but that does not mean every server implements every interaction or permits every caller to use it [S1, S6]. Additionally, FHIR standardizes terminology binding mechanisms, allowing systems to reference established coding vocabularies such as Logical Observation Identifiers Names and Codes, Systematized Nomenclature of Medicine, and RxNorm. A code-system identifier, a code, a value set and a binding are different concepts. The resource profile, binding strength, code-system version and local use affect interpretation; terminology bindings alone do not guarantee identical clinical meaning across organisations [S5]. Transport mechanisms, bundle structures, and search parameter syntax are likewise rigorously defined in the core specification, ensuring predictable foundational data transmission [S1]. Validation can check selected structural and terminology constraints; passing those checks does not demonstrate complete clinical correctness or absence of integration errors [S5, S6].

What FHIR Does Not Standardise: Workflows and Edge Cases

FHIR includes workflow resources, patterns and execution-related mechanisms. It does not prescribe one complete workflow for every institution or resolve all local business rules [S4]. For example, while FHIR defines a medication request resource, it does not dictate internal hospital routing rules for pharmacy approval, pharmacist verification overrides, or automated drug allergy escalation pathways. These operational nuances vary significantly between healthcare organizations. Moreover, FHIR does not solve the fundamental challenge of patient identity matching across unlinked health systems, nor does it govern local billing code reconciliation or proprietary clinician scheduling preferences [S2]. This is why implementation guides and regional profiles are necessary to bridge the gap between core FHIR standards and practical clinical deployment [S1]. Recognizing these limitations prevents organizations from assuming that FHIR compliance alone guarantees seamless operational workflow integration across disparate clinical environments [S2]. A workflow review should identify who owns each state change, what an error means and how an incomplete handoff is reconciled. Those are implementation questions that resource-schema conformance alone cannot answer [S4].

Proposed Design Scenario: Multi-Facility Interoperability Integration

To illustrate these principles in a practical context, consider a synthetic enterprise scenario involving an unnamed hypothetical health network, a multi-facility healthcare network integrating disparate regional clinics [S1]. The hypothetical network proposes designing an auxiliary clinical documentation assistant application intended to write patient updates back to three distinct electronic health record vendor platforms [S2]. While all three vendor systems support FHIR REST endpoints, Vendor A accepts standard condition resources, Vendor B requires specific local extension fields for billing categorization, and Vendor C enforces custom rate-limiting rules on POST requests [S3]. The proposed architecture handles these discrepancies by applying custom transformation middleware on top of base FHIR specifications, with the objective of meeting the selected profiles and workflow requirements; successful write-back would still need to be tested. This synthetic case underscores why vendor evaluation must probe deeper than simple marketing claims of FHIR compliance, validating actual implementation guide compatibility and workflow orchestration requirements [S1]. The proposed test would include rejected writes, missing mandatory fields, version mismatches and downstream state reconciliation. No write-back result, clinical deployment or corruption-free outcome has been measured in this scenario.

Evaluating Vendor Claims: Security and Compliance Realities

When hospital chief information officers and procurement committees evaluate third-party health technology solutions, vendor representatives frequently claim full FHIR integration capabilities [S3]. To separate marketing claims from technical reality, evaluators must ask precise questions regarding resource coverage. Specifically, leadership should inquire: Which exact FHIR resources does your tool read from our electronic health record? Which ones does it write back? Does your system write condition, medication request, and observation resources, or merely append unstructured Portable Document Format files via document references [S2]? Furthermore, buyers must verify what security mechanisms protect data in transit and at rest, and assessing the applicable privacy obligations separately; technical mechanisms alone do not establish legal compliance [S3]. Due diligence at resource and workflow levels can expose incompatibilities before procurement, while patient safety and administrative benefit require their own evidence [S1, S4]. An audit should record its test environment, resource coverage and unresolved limits, rather than imply that a checklist makes sensitive records immune to exposure [S3].

Operational Limits, Tradeoffs, and Future Horizons

HL7 FHIR represents a monumental leap forward for healthcare interoperability, yet inherent operational limits and architectural tradeoffs remain [S1]. Maintaining custom implementation guides across evolving FHIR release versions introduces ongoing maintenance overhead for IT departments. Furthermore, real-time data exchange introduces expansive cybersecurity attack surfaces that require robust encryption, granular access controls, and comprehensive audit logging [S3]. Despite these ongoing challenges, mastering the boundaries of FHIR enables healthcare organizations to deploy sophisticated clinical data applications effectively [S1]. By understanding what the standard provides out of the box and where custom workflow orchestration is required, healthcare leaders can architect resilient, interoperable digital ecosystems that enhance patient care coordination, streamline administrative processes, and support long-term clinical innovation while explicitly reviewing residual security, clinical and legal risks [S3]. For this proposed evaluation, a useful acceptance record would name the FHIR release, tested server configuration, implementation guide, supported interactions and unresolved workflow exceptions. The record should separate a successful interface test from evidence of clinical benefit; neither the specification nor an illustrative architecture establishes uninterrupted service.

Conceptual evaluation map connecting FHIR release, resource/profile scope, configured capabilities and local review.

Official background videos

External publisher context. These recordings do not demonstrate GPIRL products or validate the proposed designs.

DevDays — Simone Heckmann - Introduction to FHIR | DevDays Redmond 2019
FHIR introduction officially curated by HL7; illustrates interoperability context while the written release remains normative.

Sources and further reading

References do not imply product certification or endorsement.

Have a related operational question? Bring this question to a GPIRL Technologies discovery discussion.