How do medical systems exchange data via HL7 and FHIR?

HL7 is not the same as FHIR

Health Level Seven International develops several standards. In many institutions, HL7 Version 2 is established for messages such as admission, transfer, lab orders, or findings. Such messages typically consist of segments and are triggered by events. Local variants are common; therefore, the statement "we speak HL7" is not sufficient as an interface description.

FHIR – Fast Healthcare Interoperability Resources – uses clearly defined resources such as Patient, Observation, Condition, Medication, or DiagnosticReport. FHIR Release 4 in version 4.0.1 is a widely used stable basis. Resources can be represented in JSON or XML and exchanged via standardized REST interactions such as read, create, update, and search. Documents, messages, and transactions are also possible.

Profiles clarify the use case

The FHIR core specification is intentionally international and flexible. An implementation guide narrows it down for a specific use case: mandatory elements, cardinalities, search parameters, terminologies, and extensions are defined in profiles. A CapabilityStatement describes which resources, profiles, and interactions a server actually supports.

For the German hospital sector, gematik specifies FHIR-based interfaces with ISiK – Information Technology Systems in Hospitals. The respective binding or project-related version must be explicitly agreed upon; a release candidate is not automatically a productive specification. Similarly, terminologies such as ICD, SNOMED CT, or LOINC are only interoperable if version, ValueSet, and binding are clearly defined.

An exchange project requires more than just a data format

Before implementation, both parties should clarify at least:

• the professional use case and leading system,
• FHIR or HL7 version and specific implementation guide,
• patient, case, service provider, and organization identities,
• code systems, ValueSets, and handling of unknown codes,
• generation, modification, cancellation, and duplicate handling,
• error responses, retries, order, and transaction boundaries,
• authentication, authorization, transport encryption, and auditing,
• test data, conformity testing, and end-to-end acceptance.

FHIR itself is not a complete security protocol. The official specification recommends TLS for production data, authenticated clients, and risk-appropriate access control; for web-based scenarios, OAuth and SMART on FHIR may be considered. Medical purpose and risk management remain relevant even with standardized data exchange: a syntactically valid value can be clinically incorrect, outdated, or assigned to the wrong patient.