FHIR (Fast Healthcare Interoperability Resources)

FHIR models all exchangeable clinical and administrative data as discrete, modular resources. Each resource, such as a Patient or MedicationRequest, is a self-contained unit with a known identity and a common set of metadata. This granular approach allows systems to request and update only the specific data needed, avoiding the overhead of monolithic documents. Resources are the core building blocks, and all interactions in the API are operations on these resource instances, enabling a flexible and composable data model.

FHIR leverages a standard RESTful API protocol, making healthcare data accessible via simple HTTP methods. Key operations include:

• Create (POST): Add a new resource to a server.
• Read (GET): Retrieve a specific resource by its ID.
• Update (PUT): Replace an existing resource entirely.
• Search (GET): Query for resources based on defined parameters like patient name or date of birth. This stateless, web-centric approach dramatically lowers the barrier to entry for developers familiar with modern web architectures.

The 80/20 rule is central to FHIR's design. The base specification covers the 80% of common, global use cases. For the remaining 20% of specialized needs, FHIR provides a formal Extension mechanism. This allows implementers to add custom data elements to any resource without modifying the core definition. Crucially, a system that doesn't understand an extension can safely ignore it, ensuring that adding proprietary data never breaks interoperability with other conformant systems.

Every FHIR resource is designed to be both human-readable and machine-processable. The primary representation is JSON or XML, which are easily parsed by software. However, the specification also mandates that a resource can contain an embedded XHTML narrative. This human-readable summary ensures that a clinician can always view the critical information in a web browser, even if the receiving application cannot fully parse the structured data, acting as a crucial safety net for clinical data integrity.

Semantic interoperability is achieved through formal terminology bindings. Every coded element in a FHIR resource is linked to a ValueSet, which defines the allowed set of codes from a CodeSystem like SNOMED CT or LOINC. The binding strength (e.g., required, extensible) dictates how strictly a system must adhere to the specified codes. This mechanism ensures that a 'diagnosis' or 'lab result' means exactly the same thing across different organizations and software systems, enabling reliable clinical decision support and analytics.

FHIR follows a stateless client-server architecture, meaning each request from a client to a server must contain all the information needed to understand and process it. This simplifies server design and improves scalability. The architecture is also layered, allowing for intermediaries like FHIR Facades. A facade can present a standards-compliant FHIR API while translating requests in real-time to a legacy backend system, such as an older HL7 v2 interface or a SQL database, enabling modernization without a costly rip-and-replace.