HL7 and FHIR are two ways health systems send data to each other. HL7 (version 2) sends short, coded messages when something happens, like a patient being admitted. FHIR sends and receives data through a web API, one type of record at a time. Which one you need depends on what your hospital or health information exchange (HIE) can send you, not on which one is newer.
We run into this when a health center asks how to get hospital data into Salesforce. Here's the plain version.
The short answer
| HL7 v2 | FHIR | |
|---|---|---|
| What it is | Coded text messages sent when something happens | A web API with standard record types |
| How data moves | The sender pushes it to you | You request it, or subscribe to changes |
| Looks like | Lines of text with fields separated by vertical bars, in segments | Structured data (JSON) such as a Patient or an Observation |
| Age | Since the 1980s, still very common in hospitals | Newer, built for modern apps and APIs |
| Where you see it | Hospital feeds, many health information exchanges | Patient apps, newer EHR APIs, federal rules for certified EHRs |
| What Salesforce needs | A data model and a pipeline that translates each message | A data model and a connection that calls the API |
What HL7 looks like in practice
An HL7 message is a block of text. Each line is a segment, like PID for the patient and PV1 for the visit, and each segment holds fields in a fixed order. A person can read it with practice, but Salesforce can't. Something has to read each segment and decide which Salesforce field it belongs in.
That mapping is most of the work. On a recent project connecting a community health center to its regional exchange, we mapped every HL7 segment to its place in Salesforce, so the integration team knew exactly what to send where.
What FHIR looks like in practice
FHIR splits health data into standard resources: Patient, Encounter (a visit), Condition (a diagnosis), Observation (a result), MedicationRequest, and more. Each one is a clean, labeled record you can request over the web. For a developer, that's easier to work with than a stream of messages. It also means more of your EHR vendor's data can be reached the same way.
Federal rules have pushed EHR vendors toward FHIR-based APIs, so more systems offer one. That doesn't mean your hospital or exchange sends you FHIR today. Ask them.
So which one do you need?
It's your source's answer, not your preference.
- Your hospital or exchange sends HL7 messages. Plan for a pipeline that translates them, plus a Salesforce data model to hold the result.
- Your EHR offers a FHIR API. Plan a connection that pulls the records you need, plus the same kind of data model.
- Both are available. Pick the one that gives your team the data it needs, with the least upkeep. Often that's whichever your partner already knows how to run.
In both cases, the part people forget is Salesforce itself. Hospital visits, diagnoses, medications and allergies don't have a place in a standard org, so you build one.
What Salesforce needs, whichever you choose
- A data model for the clinical data you want to keep, such as visits, diagnoses, observations and medications.
- A secure integration user, so the connection has only the access it needs.
- Field ownership, so incoming data never overwrites what your team entered. We use a review step for this.
- An error log, so failed messages are visible and nobody wonders where a record went.
- Security and privacy review. Health data needs tight access. HIPAA also depends on your own policies and training.
Want to know more?
If you're deciding between HL7 and FHIR, or you're not sure what your hospital or exchange can send, we'll look at it with you. It takes 30 minutes, costs nothing, and you leave with a clear picture. Contact us or book a free health check.