If you administer an EMR, you'll eventually be on a call about an "HL7 feed" or a "FHIR API." Understanding what these standards are — and where each fits — makes you far more effective at managing integrations, scoping vendor projects, and troubleshooting when a feed goes quiet. You will not be writing interface code by hand, but the moment you can speak this vocabulary, the conversations stop being intimidating. Here's the practical version.
HL7 is the family; the standards are the members
Health Level Seven International (HL7) is the standards body. A common point of confusion is treating "HL7" as a single format, when over the years it has published several distinct standards that look nothing alike. The three you'll meet most often are HL7 v2 messaging, C-CDA documents, and FHIR — and they coexist rather than replace one another.
| Standard | Form | Typical use |
|---|---|---|
| HL7 v2 | Pipe-delimited messages | Lab orders/results, ADT, charges — the workhorse of clinic interfaces |
| C-CDA | XML clinical documents | Care summaries, transitions of care |
| FHIR | RESTful API, JSON/XML resources | App access, patient data exchange, modern integrations |
HL7 v2: the legacy backbone
HL7 version 2 still moves a huge share of real-world clinical data. Messages are made of segments (like PID for patient identity or OBX for observations) separated by pipes and carets. ADT (admit/discharge/transfer) messages keep demographics in sync; ORM/ORU messages handle orders and results. It's old, quirky, and everywhere — most lab and imaging interfaces you manage will be v2. Its quirk is also its weakness: the standard leaves room for local variation, so two systems can both claim to speak v2 and still need a custom mapping to actually understand each other. That is why a v2 interface is rarely plug-and-play and almost always involves a build-and-test phase.
C-CDA: the document standard
The Consolidated Clinical Document Architecture defines structured clinical documents — for example, a Continuity of Care Document summarizing problems, medications, allergies, and results. C-CDA is how a lot of care-summary exchange and transitions of care happen. Where a v2 message is a small, real-time event ("this result is ready"), a C-CDA is a snapshot of a patient at a point in time, meant to travel between organizations when a patient is referred, discharged, or changes providers.
FHIR: the modern API
What makes FHIR different in practice is that it uses the same web technologies your IT team already knows — standard HTTP requests, JSON payloads, and OAuth-style authorization — so a developer who has never touched healthcare can read a FHIR response and understand it. That accessibility is precisely why regulators chose it as the backbone for patient and third-party app access.
How it fits together in your environment
- Your lab and imaging interfaces are probably HL7 v2, often through an interface engine.
- Your care-summary exchange may use C-CDA.
- Your patient-access and third-party app connections likely use FHIR APIs.
- An interface engine often sits in the middle, translating and routing between systems.
What this means for you as an admin
- Keep an inventory of every interface: source, destination, standard, and message types.
- Know who owns each endpoint (lab, HIE, app vendor) for troubleshooting.
- Understand that v2 and FHIR coexist — adopting FHIR rarely means retiring your v2 feeds.
- Reference HL7's published standards and the US Core IG rather than relying on tribal knowledge.
You don't need to write interfaces by hand, but knowing this vocabulary turns integration conversations from mysterious to manageable. When a vendor says a connection "uses FHIR" or "is just a v2 result feed," you'll know roughly what to expect for effort, testing, and ongoing maintenance — and you'll ask sharper questions before signing off.