“We need HL7/FHIR integration” covers a wide range of actual work, and vendors quoting it without asking what systems you’re connecting are guessing. Here’s what the work actually breaks down into.
Mapping, not just connecting
The hard part of HL7/FHIR integration isn’t the protocol — it’s mapping fields between two systems that model the same information differently. A lab result field in your LIS and the corresponding field in a receiving EHR rarely line up one-to-one. Most integration timelines slip because this mapping work is underestimated at the proposal stage.
Message types matter
ADT (admit/discharge/transfer), ORM (orders), and ORU (results) each have different validation requirements and failure modes. A vendor should be able to tell you which message types your integration involves before quoting a timeline — if they’re not asking, they haven’t scoped it.
Testing against real transaction data, not sample messages
Integrations that pass testing against clean sample HL7 messages and then fail in production almost always failed because the test data didn’t include the edge cases — missing fields, non-standard formatting, duplicate patient records — that real systems actually produce.
What a properly scoped engagement looks like
An assessment phase (what systems, what message types, what’s already in place), a build phase against a fixed integration spec, a validation phase against real (de-identified) transaction data, and a support phase once it’s live — because integrations need monitoring, not just a go-live date.