What is HL7 FHIR?
FHIR (Fast Healthcare Interoperability Resources) is the modern standard for exchanging healthcare information between systems. This is the foundation of everything built in this lab.
The Interoperability Problem
Healthcare systems do not talk to each other. A hospital in Bratislava runs one EHR system. A general practitioner uses another. A pharmacy uses a third. Each has its own data format, its own identifiers, its own way of representing a patient or a diagnosis. When a patient moves between systems, data gets lost, re-entered manually, or not transferred at all.
This is the interoperability problem. It causes medical errors, duplicate testing, inefficiency, and in the worst cases, patient harm. The problem has existed for decades. Multiple standards attempted to solve it — HL7 v2, HL7 v3, CDA — with limited success.
FHIR was designed to finally solve this. It combines modern web technologies (REST, JSON, HTTP) with healthcare domain expertise. The result: a standard that developers can actually implement without a decade of specialized knowledge.
HL7 FHIR — The Standard
HL7 FHIR stands for Health Level Seven Fast Healthcare Interoperability Resources. It is developed and maintained by HL7 International — the standards development organization responsible for most healthcare data standards globally.
FHIR was first published in 2014 as a draft standard and reached normative status (stable, production-ready) with R4 in 2019. R4 is the current primary version used in production systems worldwide. R4B was a minor update in 2022. R5 is the latest full version (2023), but R4 remains dominant in production deployments.
Core Concepts
Resource
The fundamental unit of FHIR. Everything is a Resource: Patient, Observation, Condition, Encounter, Medication, DiagnosticReport. Each Resource is a structured JSON or XML document with a defined schema.
REST API
FHIR exposes a RESTful HTTP API. You interact with FHIR servers using standard HTTP methods: GET (read/search), POST (create), PUT (update), DELETE (delete). The base URL pattern is: [base]/[ResourceType]/[id].
JSON / XML
FHIR resources can be serialized as JSON or XML. JSON is the default in modern implementations. A Patient resource in JSON is a standard JSON object with a resourceType field set to 'Patient'.
Bundle
A container for multiple FHIR resources. Used for grouping, transporting, and processing resources together. Bundle types: transaction (all-or-nothing), batch (independent entries), collection, and document.
CapabilityStatement
The FHIR server's declaration of what it supports. GET [base]/metadata returns the CapabilityStatement — a machine-readable document listing supported resources, operations, search parameters, and FHIR version.
Identifier
A business identifier for a resource — for example, a patient's national ID number or hospital patient number. Not the same as the FHIR resource id. Resources can have multiple identifiers from different systems.
FHIR REST API — How It Works
FHIR uses standard HTTP. If you know REST APIs, you already understand the fundamentals. The URL structure is consistent:
FHIR in Slovakia and the European Health Data Space
The European Health Data Space (EHDS) is EU legislation that mandates cross-border health data sharing across all EU member states. The EHDS regulation was formally adopted in 2024. It designates FHIR as the primary technical standard for data exchange through the European Health Record Exchange Format (EHRxF).
In Slovakia, the national health information system is managed by NCZI (Národné centrum zdravotníckych informácií — National Health Information Centre). Slovakia must comply with EHDS requirements, which means Slovak healthcare systems will need to implement FHIR interfaces for cross-border data sharing.
This lab (FHIR.sk) is a personal learning project exploring these concepts. It is not affiliated with NCZI, HL7 Slovakia, or any official body.