FHIR (Fast Healthcare Interoperability Resources)
Term 53 of 68 in the ERPStack technical glossary
What is FHIR (Fast Healthcare Interoperability Resources)?
FHIR (Fast Healthcare Interoperability Resources) is a standard for healthcare data exchange developed by HL7 International, defining a set of REST APIs and JSON/XML data formats for electronic health records (EHR) interoperability.
FHIR (Fast Healthcare Interoperability Resources) at a glance
- Current release
- FHIR R5, published by HL7 as version 5.0.0; R4 and R4B remain widely deployed
- Model
- Modular resources — Patient, Observation, Encounter — exchanged over 1 RESTful API
- Format
- 2 interchangeable wire formats, JSON and XML, over the same resource definitions
- Extension mechanism
- Profiles constrain resources for 1 use case without forking the base specification
- Integration reality
- Target the counterpart's version — R4 is still the common denominator in production estates
- Built with
- Next.js 16 API routes mapping FHIR resources to PostgreSQL 18 tables through Drizzle ORM 0.45, payloads validated with Zod 4, RBAC and SSO enforced, hosted on AWS with an Immutable Audit Trail
- Numbers that matter
- R5 is version 5.0.0; R4 remains the common denominator; 2 wire formats, JSON and XML; 3 core resources — Patient, Observation, Encounter
- Adjacent standards
- HIPAA safeguards, SOC 2 controls and ISO 27001 information security
- Commonly paired with
- REST clients, a PostgreSQL Database, RBAC, SSO and an Immutable Audit Trail
- Version arithmetic
- R5 is 5.0.0, R4B is 4.3.0 (May 2022) and R4 is 4.0.1 (October 2019). An integration targets 1 of the 3; translating between them is a project, not a configuration setting.
- Where it lands
- healthcare and biotech estates mapping resources into PostgreSQL 18 through Drizzle ORM 0.45, validated with Zod 4, with RBAC, SSO and an Immutable Audit Trail over every read.
How FHIR (Fast Healthcare Interoperability Resources) works in production
The ERPStack approach to FHIR (Fast Healthcare Interoperability Resources)
We build FHIR v4-compliant patient data layers for healthcare portals, implementing resource endpoints for Patient, Observation, and Medication resources with AES-256 encryption on all ePHI fields.
Frequently asked questions about FHIR (Fast Healthcare Interoperability Resources)
What is FHIR and why did it replace older exchange formats?
Fast Healthcare Interoperability Resources is HL7's standard for exchanging clinical data as modular resources over a RESTful API. Its predecessors were document-oriented and heavy to implement; Interoperability Resources use ordinary web patterns and JSON, so a competent web team can integrate without specialist middleware. R5 is the current published release, while R4 and R4B remain widely deployed in production.
Which FHIR version should an integration target?
Whatever the counterpart supports, which in practice is often R4 rather than the newest release. Interoperability Resources evolve, and healthcare systems upgrade slowly, so an integration is constrained by the least current participant. Designing your internal model so the version is an adapter concern — rather than assuming a single release throughout the codebase — keeps a later migration from touching everything.
Does using FHIR make a system HIPAA compliant?
No. Interoperability Resources define how clinical data is represented and exchanged; HIPAA governs how protected health information must be safeguarded. A perfectly conformant API with weak access control and no audit trail is a compliance failure with excellent data modelling. The 2 concerns are complementary and must both be designed for, since neither implies the other.
How do profiles work?
They constrain a base resource for a specific context — required fields, permitted code systems, cardinality — without altering the standard itself. Interoperability Resources are deliberately broad, so a national or organisational profile narrows them to something implementable. Validating against the profile as well as the base specification is what catches the integration bugs that pass generic validation but fail the counterpart's expectations.