"Do you have HL7 experience?" is one of the most common questions in a healthcare engineering interview, and it's usually the wrong one. HL7 v2 and FHIR are not the same job. V2 is about messages, segments, triggers, and interface engines, plus whatever local variations a given hospital has layered on over twenty years. FHIR is about resources, profiles, references, REST APIs, and OAuth. Both count as "healthcare interoperability" on a resume. The engineering mindset behind them is genuinely different, and treating "HL7/FHIR" as a single checkbox is how hiring managers end up surprised six weeks into a project.
Same standards body, different engineering muscle
HL7 v2 was HL7's first widely adopted information exchange standard, built around messages composed of reusable segments that communicate healthcare information between a sending and receiving system, patient admissions, lab orders, discharges. It's message-based, event-triggered, and every hospital's implementation tends to carry its own local dialect layered on top of the base standard, usually held together by an interface engine translating between systems.
FHIR, Fast Healthcare Interoperability Resources, is HL7's newer standard, built on REST APIs, structured resources, profiles that constrain and extend those resources for a specific use case, and standard web patterns like OAuth for authorization. It's the standard behind most modern patient-access apps, SMART on FHIR integrations, and the APIs that ONC's Cures Act certification requirements now require certified health IT to expose.
HL7 v2 vs FHIR, the engineering difference, not just the acronym difference
| Dimension | HL7 v2 | FHIR |
|---|---|---|
| Core unit | Messages built from segments | Resources, composed and referenced |
| Interaction style | Event-triggered messaging | RESTful API calls, plus messaging and document paradigms |
| Format | Pipe-delimited text | JSON or XML |
| Typical tooling | Interface engines, custom parsers | API gateways, FHIR servers, SMART app frameworks |
| Authorization model | Network- and interface-level trust | OAuth 2.0 / SMART on FHIR |
| Where it shows up | Internal hospital system-to-system messaging (ADT, orders, results) | Patient-facing apps, payer APIs, modern EHR integrations |
| Local variation | High, every site's v2 implementation differs | Lower at the base spec, but profiles still vary by implementation guide |
Both are healthcare interoperability. The muscle you use to debug a rejected HL7 v2 ADT message from a legacy interface engine is not the same muscle you use to design a FHIR resource model against a US Core profile. Neither is more "real" engineering than the other, they're just different jobs.
The mistake: hiring for "HL7/FHIR" as one checkbox
It's an easy mistake to make. Both terms show up together on job descriptions, both show up together on resumes, and a candidate who's touched either one will often list "HL7/FHIR" as a single line. But a strong v2 interface engineer parsing custom Z-segments from a twenty-year-old lab system may have never built a REST API in their life, and a FHIR-fluent engineer who's shipped SMART on FHIR apps may have never had to reverse-engineer an undocumented local v2 dialect at 2am during a go-live. Screening for the acronym instead of the actual work tells you almost nothing about which of those two people you're hiring.
The mistake is hiring for "HL7/FHIR" as a single checkbox.
What to ask instead: five questions about production scars
Standards knowledge matters less than production experience. These five questions tend to surface who's actually done the work, on either standard:
1. What systems did you integrate?
Specific system names and versions, an EHR, a lab system, a payer API, tell you far more than "healthcare interoperability" as a category. Vague answers here are a signal to dig deeper.
2. Read or write?
Consuming data from a system and writing data back into it are different problems with different failure modes. A candidate who's only ever read from a FHIR API hasn't dealt with the validation and conflict issues that come with writing to one.
3. Real-time or batch?
A real-time HL7 v2 interface handling live ADT events and a nightly batch FHIR bulk-export job call for different reliability and error-handling patterns. Someone who's only done batch work may not have hardened experience with live message queues.
4. How did you handle mapping and validation?
Every real integration involves mapping between a source system's model and the standard's model, plus validating that what comes across is actually usable. How someone describes this, with specifics, not generalities, is a good proxy for how deep their experience actually goes.
5. What happened when data was rejected?
This is often the most revealing question. Rejected messages and failed validations are where real integration experience shows up, how it was investigated, who was looped in, and what changed afterward. A candidate who's never had a message rejected in production probably hasn't done this at scale.
The answers to these five questions tell you more about whether someone can do the job than any amount of "yes, I know HL7 and FHIR" on a resume.
Why this matters beyond hiring
The same distinction that matters in an interview matters in project scoping. A modernization project that's mostly about exposing a legacy EHR's data through a modern patient-access API is a FHIR-shaped problem. A project connecting a hospital's internal lab, pharmacy, and ADT systems through an interface engine is a v2-shaped problem, and many real healthcare platforms need both, often at the same time, translating between the two where legacy systems still speak v2 and modern consumers expect FHIR. Scoping either kind of work as generic "HL7/FHIR integration" tends to produce the same estimation and staffing mistakes as hiring for it that way.
How Peerbits helps
Peerbits is a healthcare software engineering company that builds and integrates both HL7 v2 and FHIR-based systems, and staffs each engagement with people who've actually done the specific kind of work it needs, not a generic "interoperability" hire.
- HL7 v2 interface engineering
- FHIR API design and implementation
- SMART on FHIR app development
- Legacy-to-modern interoperability bridges
- EHR integration
- Healthcare data mapping and validation
- Healthcare cloud modernization
- Dedicated healthcare engineering teams
Peerbits builds and integrates this software directly, Peerbits is not a staffing agency and does not claim generic "HL7/FHIR certified" credentials beyond what's verifiable for the specific engineers on a given engagement.
The takeaway
HL7 v2 and FHIR are both healthcare interoperability standards, and both belong on a healthcare engineering team's resume list. But they're not the same engineering job, and hiring — or scoping a project — as if they were is how teams end up with a mismatch they only discover mid-integration. Ask about the systems, the direction, the timing, the mapping, and what happened when something got rejected. That tells you far more than the acronym ever will.
Building or staffing an HL7 or FHIR integration?
Tell us what systems are involved, which direction the data needs to flow, and what's already in place, we'll help you scope it as what it actually is, not a generic "HL7/FHIR" line item.
Discuss Your Integration ProjectFrequently asked questions
No. Both come from HL7 International, but HL7 v2 is a message-based standard from the late 1980s built around segments and trigger events, while FHIR is a newer, REST API-based standard built around structured resources. They solve overlapping problems with different engineering approaches.
Not entirely, and not quickly. FHIR is the standard behind most new patient-facing and API-based integrations, but HL7 v2 remains deeply embedded in existing hospital interface engines and is unlikely to disappear from internal system-to-system messaging any time soon.
Some engineers do have real depth in both, but it shouldn't be assumed from a resume line. Screen for the specific systems, direction (read/write), and failure scenarios a candidate has actually handled on each standard, rather than treating "HL7/FHIR" as one qualification.
Ask about production scars rather than standards knowledge: which systems they integrated, whether they were reading or writing data, whether the integration was real-time or batch, how they handled mapping and validation, and what happened when data was rejected.
Many hospital systems built their interface engines and internal messaging around HL7 v2 years or decades ago, and replacing that infrastructure is a significant undertaking. FHIR is increasingly used for new, API-based, and patient-facing integrations, often alongside, rather than instead of, existing v2 messaging.
Peerbits builds and integrates both HL7 v2 interfaces and FHIR-based APIs, staffing each engagement with engineers experienced in the specific standard, direction, and systems the project actually requires.
