Anyone who’s built healthcare software has bumped into the FHIR vs HL7 v2 question at least once. Both are valid. Both ship to production. The trick is matching the right one to the integration in front of you. Here’s the short version we hand new engineers.
What HL7 v2 is good for
HL7 v2 is the workhorse of hospital integrations. It’s a pipe-delimited message format, mature since the 1980s, and it’s what 90% of existing EHR systems already speak. If you’re integrating with an established hospital or lab system, HL7 v2 is almost always already there. Don’t fight it.
What FHIR is good for
FHIR (Fast Healthcare Interoperability Resources) is the modern standard — REST APIs, JSON, OAuth, the things web engineers already know. It’s what you want when:
- You’re building a new system from scratch with new integration partners.
- You need to expose healthcare data to a mobile app or a modern web frontend.
- You’re dealing with patient-facing data flows (portals, scheduling, records).
The decision tree
Ask three questions, in order:
- Does the partner system speak FHIR natively? If yes, use FHIR.
- Does the partner system speak HL7 v2 already? If yes, use HL7 v2 — don’t try to force a FHIR endpoint where one doesn’t exist.
- Are you starting fresh? Use FHIR. Future-proof the integration.
The hybrid pattern
Many projects end up doing both — HL7 v2 to talk to legacy clinical systems, FHIR to talk to anything new. That’s fine, as long as you put a translation layer between them and don’t let either format leak across the boundary.