HL7 or FHIR: A guide to help you decide
Expand the table of contents
HL7 or FHIR – How to choose the right integration strategy for your hospital information system
In today’s hospital IT landscape, two worlds collide: the growing need for integration between patient data management systems (PDMS), hospital information systems (HIS), medical devices, and external systems meets historically established HL7 v2 infrastructures. [1] Modern, often REST-based APIs are coming into contact with event-driven HL7 messages. This raises the question: Should you stick with HL7 or switch to FHIR now?
To help you make an informed decision, this article highlights the differences between the standards and provides a foundation for future developments.
HL7 v2 – The classic
HL7 (Health Level Seven) has been the de facto standard in many hospitals for decades; it is well-established and a robust choice for transmitting patient and laboratory data. Message exchange is event-driven and text-based. Each message consists of a series of segments, which are further divided into fields, components, and subcomponents. While the specification at the segment level is still interpreted uniformly (e.g., what a PID segment is used for), interpretation at the field level is significantly less uniform and often requires individual adjustments by one or more communication partners. Or, to put it in the words of Captain Barbossa: “Is the standard more a set of so-called guidelines than actual rules?” [2]
Furthermore, the structure of HL7 messages is only partially suitable for further processing and requires extensive mapping in the target system.
FHIR – The modern approach
FHIR (Fast Healthcare Interoperability Resources) primarily relies on REST, but also supports messaging- and document-based approaches. Patients, observations, and similar data are mapped to resources and processed using HTTP verbs (GET, POST, PUT, DELETE). There is a clearly defined data model that can be flexibly extended through profiles. Libraries are often already available for various programming languages, so you can frequently get started right away without first having to develop your own parser.
Even with FHIR, mapping to the target system will not be entirely eliminated, but since the API already provides structured objects such as patients or observations, further processing is significantly easier. For Germany, there are comprehensive FHIR profiles designed to ensure uniform usage. Gematik, for example, is increasingly relying on FHIR-based profiles in its telematics infrastructure and provides corresponding specifications for Germany. [3]
HL7 v2 and FHIR compared
Both standards essentially serve the same purpose: exchanging treatment-related data between different systems. However, their approaches differ significantly: In HL7, systems exchange information using the push model, while FHIR provides data in a structured format.
Historically, HL7 stems from a mindset in which different systems were aware of one another and kept track of who had already received which information. With FHIR, on the other hand, clients retrieve the data they need and can opt to be notified of changes via the FHIR Subscription Framework if necessary.
With HL7, secure operation is ensured through trusted proxies or VPNs (or sometimes omitted). FHIR recommends encrypted connections for data protection as well as OAuth 2.0 for authentication, and even publishes implementation guidelines. This should make it easy for third-party providers to connect apps to various systems. While data exchange with HL7 was almost always limited to a single hospital’s systems, FHIR is explicitly designed for cross-system data exchange, particularly within telematics infrastructure.
The following table briefly summarizes the comparison:
| Kriterium | HL7 v2 | FHIR |
| Paradigma Messaging | Messaging (Push) | REST + Pull |
| Data model | position-based | resource-based |
| Interoperability | limited | high |
| Implementation | complex | moderate |
Decision-making guide for HL7 v2 or FHIR
When should you choose HL7 v2 or FHIR?
There are essentially two scenarios:
- Modernizing legacy systems: Your existing software (e.g., PDMS, HIS) uses HL7 v2 to communicate with other systems.
- New development: You are planning new software and need to choose a standard.
If your existing software needs to communicate exclusively with other long-standing software, there is no reason to make hasty decisions. HL7 will continue to serve you well for a long time and remain in use. However, you should take a look at your software and documentation. Although maintenance requirements are minimal, the software architecture is often outdated, the original developers are no longer with the company, and the documentation is incomplete or only partially available. Even simple maintenance tasks and adjustments can quickly become very time-consuming here, simply because the knowledge of the system’s current state must be rebuilt from scratch. In the long term, however, you should still invest resources in FHIR before your competitors do. Otherwise, once two competitors support FHIR, things could get difficult in the next tender.
If you’re developing new software, things get a bit more complicated. While the future-proofing of HL7 v2 is limited, if your software needs to communicate with a specific EHR system that only offers HL7 v2, you’ll have little choice. Either you use existing third-party converters and bring their complexity into your organization, or you develop the interface yourself. Here, you should ensure a clean architecture, sufficient documentation, and test-driven development—and again, remember Captain Barbossa: “These are guidelines, not rules.” When in doubt, your software should be flexible rather than strictly adhering to the specification.
If your software is intended to communicate with gematik’s Telematics Infrastructure (TI) [4] or the European Health Data Space (EHDS) [5], FHIR is practically unavoidable. It is more future-proof, and because it is based on international standards, the interface will not pose a major hurdle for your developers.
Conclusion
HL7 v2 has reached its limits, especially in a world where patients receive outpatient care, wearables and health apps provide data, and systems must communicate across institutional boundaries. FHIR is the future, not only because gematik and the EHDS are committed to it, but because it is scalable, secure, and developer-friendly.
Of course, HL7 v2 won’t disappear overnight. In the short term, a hybrid approach (HL7 v2 for legacy systems, FHIR for new integrations) will be unavoidable. In the long term, however, you should invest resources in FHIR—otherwise, you risk falling behind the competition.
The crucial question is therefore no longer whether you will implement FHIR, but when and how strategically you will manage the transition.
Notes:
[1] HIS (Hospital Information System) and PDMS (Patient Data Management System) are core digital systems in hospitals. The HIS is the central administrative and documentation software for the entire patient journey, while the PDMS, as a highly specialized subsystem, supports intensive care units and operating rooms in the real-time collection of device data and intensive care medicine. Here you will find more information about PDMS and KIS in German.
[2] Captain Hector Barbossa is a character from the feature film ‘Pirates of the Caribbean’ (2003). He makes this remark in response to Elizabeth Swann, who invokes the pirates’ ‘code’ to avoid being marooned on an island.
[3] gematik GmbH (National Agency for Digital Medicine) is the central body in Germany responsible for the establishment, operation, and further development of the Telematics Infrastructure (TI). It connects stakeholders in the healthcare sector to securely implement digital applications such as e-prescriptions, the electronic health card (eGK), and the electronic patient record (ePA).
[4] The telematics infrastructure (TI) is the secure, closed digital network in the German healthcare system that connects doctors, hospitals, pharmacies, and health insurance companies. Managed by gematik, it enables the rapid, data-protection-compliant exchange of medical data.
[5] The European Health Data Space (EHDS) is an EU-wide initiative that enables the secure exchange and use of electronic health data across national borders. It came into effect on March 25, 2025, to improve patient care through easy access to personal data and to promote research.
Here you will find more information about FHIR.
Are you an influencer or communications professional interested in discussing HL7 v2 or FHIR? If so, please feel free to share this post with your network.
Here are some more articles from the t2informatik Blog:

David Stoermer
David Störmer is a software developer and architect with a passion for clean code and test-driven development (TDD). His interest in programming was sparked at an early age: at 15, he discovered a book on QBasic in the library and used it to produce his first sounds on his parents’ Windows 95 computer – a formative experience.
While studying media informatics, he specialized in computer vision and visualization technologies, but always kept his focus on maintainable, clearly structured code. TDD became second nature to him: “Even the most beautiful code is useless if what it’s supposed to do isn’t documented.”
In his personal life, David balances family outings to Karls Erdbeerhof with projects like home automation or renovating his own home, always with the goal of meaningfully integrating technology into everyday life.
In the t2informatik Blog, we publish articles for people in organisations. For these people, we develop and modernise software. Pragmatic. ✔️ Personal. ✔️ Professional. ✔️ Click here to find out more.


