HL7 and FHIR Integration: What to Ask Before You Sign

The standards your vendor claims to support and the integration your clinical systems actually need are rarely the same thing — here's how to close that gap.

Why this matters

Picture a 400-bed regional hospital that spent eight months and a mid-six-figure budget implementing a new EHR, only to discover that its patient monitoring systems, lab analyzers, and pharmacy dispensing cabinets still communicated through a patchwork of manual workarounds — because "FHIR-compatible" in the sales materials meant the vendor had built a single read-only endpoint for patient demographics, nothing more. The clinical informatics team had asked whether the system supported FHIR. They had not asked which resources, which interactions, or against which profile set. The answer to the first question was technically yes. The answers to the follow-up questions would have told a different story.

This kind of mismatch is the norm rather than the exception in health IT procurement. HL7 and FHIR have become marketing language as much as technical standards, and the gap between "supports HL7" and "will exchange meaningful clinical data with your existing infrastructure" is wide enough to sink a go-live timeline. HL7 v2 alone covers dozens of message event types — ADT, ORU, ORM, MDM, RDE, among others — and most sites have spent years customizing segment structures in ways that deviate from the published standard. A new device or platform claiming v2 compatibility may only implement A01 and A04 admit/discharge events, leaving your lab result routing (ORU^R01) and medication orders (RDE^O11) stranded at the interface boundary.

The regulatory context has sharpened the stakes considerably. The ONC's 21st Century Cures Act Final Rule, finalized in 2020, requires certified health IT developers to support FHIR R4-based APIs and prohibits information blocking — meaning your vendors carry legal obligations around interoperability that simply did not exist five years ago (S1). Understanding how those obligations translate into contractual deliverables is now as essential a procurement skill as evaluating hardware specifications or service-level agreements.

The decisions that shape the outcome

Which HL7 version, and which message types?

Your facility almost certainly runs HL7 v2 infrastructure that has been customized over years, and any new system needs to map cleanly to those non-standard Z-segments and variant field lengths. When a vendor says "HL7 v2.x compatible," ask them to specify the exact message events supported and whether they can accommodate Z-segments without a professional-services engagement every time the message structure changes. HL7 v3 and C-CDA documents are still in circulation for certain document-exchange use cases — referral summaries, discharge documents — so clarify whether those workflows are in scope or require a separate module.

FHIR version and profile conformance

FHIR R4 is the current stable release and the version required under the ONC Final Rule for certified APIs (S1). R4 and the earlier STU3 release are not backward-compatible, so a vendor offering an R3 endpoint is offering something that cannot automatically interoperate with R4 systems without translation logic in the middle. Beyond version, ask which FHIR resource types are supported and whether the implementation conforms to a published Implementation Guide — the US Core Implementation Guide being the most relevant baseline for US deployments (S2). Conformance to a named profile is testable and auditable; a claim of "FHIR support" is not.

SMART on FHIR and authorization architecture

FHIR APIs are only as safe as the authorization layer in front of them. SMART on FHIR, built as an open standard layered on OAuth 2.0, defines how third-party applications authenticate and scope their data access. Ask whether the vendor's FHIR server is SMART on FHIR compliant and, critically, whether it has been validated through the ONC's Inferno testing tool — a publicly available test suite that checks conformance against the standardized API requirement (S3). A vendor that cannot point you to Inferno test results is either non-compliant or simply untested.

Integration engine and middleware responsibility

Most real-world HL7/FHIR deployments route messages through an integration engine rather than running direct point-to-point connections. The critical procurement question is ownership: who is responsible for building, maintaining, and monitoring those interface maps? Some vendors supply their own engine and charge per-interface licensing fees; others expect the buyer to operate their own middleware. Neither model is inherently superior, but the costs diverge sharply and are rarely disclosed upfront. Interface build fees are not publicly standardized and vary widely by vendor and complexity — get them line-itemed in the contract before you sign.

Ongoing maintenance and version upgrades

Ask explicitly whether the vendor's product roadmap includes FHIR R5 migration, and whether that migration is covered under the existing support agreement or will trigger a separate contract. A system that is R4 compliant today but has no documented upgrade path is a technical liability on a 7–10 year equipment refresh cycle.

Common mistakes

One of the most common errors is treating "FHIR-ready" as a binary attribute. A system can expose a FHIR endpoint for a single resource type — say, Patient — and legitimately claim FHIR support. Procurement teams that do not request a capability statement often discover post-go-live that critical data flows — Observation resources for lab values, MedicationRequest for e-prescribing, DiagnosticReport for imaging results — were never in scope. The capability statement is a standard FHIR artifact available at any compliant server's /metadata endpoint; requesting it costs nothing and reveals everything.

A second mistake is underestimating the cost and complexity of HL7 v2 translation. Many organizations have accumulated fifteen or twenty years of non-standard segment usage. When a new system arrives expecting compliant v2 messages, someone must write translation logic for every exception. If that work is not scoped and priced in the statement of work before signing, it becomes change-order territory — and that is where implementation budgets reliably collapse.

Third, procurement teams often skip sandbox testing against real site data. Vendors routinely demonstrate integrations using clean, synthetic records that bear little resemblance to the messy, decades-deep patient data in a live ADT feed. Requiring a proof-of-concept with a de-identified extract of actual site data — even a few hundred records — will surface mapping failures that no polished demo ever will.

A fourth mistake, particularly common in multi-vendor environments like ASCs and specialty clinics, is assuming that one system's FHIR server will natively interoperate with another's without a formal integration agreement between the two vendors. FHIR standardizes the data model; it does not standardize the business relationships, authentication trust, or data-sharing policies that make real exchange work. Those must be negotiated separately, and the time to raise those conversations is before contracts are signed.

A practical workflow

1. Request the vendor's HL7 capability matrix and FHIR capability statement before any demo. These documents describe what is actually built, not what is on the roadmap.
2. Document your site's existing v2 message types and Z-segment customizations and share them with shortlisted vendors as a test scenario. This forces a concrete discussion of translation complexity while you still have leverage.
3. Ask the vendor to provide their ONC certification number or Inferno test results if FHIR API compliance is a stated contractual requirement. Certification records are searchable through the ONC CHPL database at no cost.
4. Itemize integration engine ownership, per-interface fees, and ongoing maintenance responsibilities as separate line items in the contract. Vague professional-services language in this area is a reliable source of budget overruns.
5. Negotiate a sandbox proof-of-concept with de-identified site data before final sign-off. Define pass/fail criteria in writing and tie them to acceptance milestones.
6. Include a version upgrade clause addressing FHIR R4-to-R5 migration cost and responsibility. Leaving this undefined creates financial exposure at the next standards cycle.

Sources

• HL7 FHIR R4 Specification — hl7.org
• ONC 21st Century Cures Act Final Rule — healthit.gov
• US Core Implementation Guide — hl7.org
• ONC Inferno FHIR Testing Tool — inferno.healthit.gov