HL7 and FHIR Integration Services

Parsing is the part everyone expects to be difficult and is not. The difficulty lives in identity, ordering, acknowledgement and the gap between what a specification says and what a production system sends. A specification describes a well-formed message. A real sending system adds proprietary segments, populates optional fields inconsistently, and behaves differently under load than it does in a test environment. Interfaces built against documentation alone fail their first production week, which is why we build against captured traffic instead.

HL7 v2 organizes traffic into message families, each with its own trigger events and structure. In practice a small number of families account for nearly all production volume, and scoping an interface project means stating explicitly which message types are handled, which are acknowledged and ignored, and what happens to anything unexpected. Estates that never made that decision consciously tend to have interfaces that silently discard messages nobody knew were arriving.

FHIR organizes data into resources rather than messages, and the practical work is determining which resources a given vendor actually serves, at which version, and how conformant the implementation is. Vendor capability statements describe intent. Testing against the live endpoint describes reality, and the two diverge often enough that we confirm per resource during scoping rather than accepting a published list. Some resources are still served under older FHIR versions even where the endpoint is described as R4.

This decision is made badly more often than any other in healthcare integration, usually by treating FHIR as automatically preferable because it is newer. It is not. FHIR answers queries on demand and suits retrieval, patient-facing applications and analytics. HL7 v2 pushes events as they occur and suits real-time clinical workflow, which is why it still carries most production traffic. Choosing by recency rather than by requirement produces projects that cost more and deliver later than the alternative would have.

Bridging is where the two standards meet in practice, and it is a mapping problem rather than a format conversion. An ADT message and a FHIR Patient resource do not carry the same semantics, and a translation that treats them as equivalent loses information that matters. Merge handling in particular has no clean FHIR equivalent, which means the bridge has to hold identity logic rather than pass it through. Done properly, bridging lets an organization modernize its consumers without touching its source systems.

Interfaces pass testing and fail in production because test data is clean and real traffic is not. Our approach is to test against captured production messages, exercise failure paths deliberately, and validate conformance with the same tooling a certifying body would use. For organizations pursuing ONC certification, conformance testing is not a final gate but a design constraint, and building toward it from the start costs considerably less than remediating toward it afterward.

We build interfaces on whichever engine you already run. Most of our work happens in the Mirth lineage because that is what most of our clients have, but the standards work is the same regardless of platform, and we deliver on commercial engines and managed networks where that is what a client operates. A consultancy that can only work in one engine will recommend that engine to everyone, which is not advice. If you have no engine yet, the selection is its own decision and worth making on your requirements rather than on ours.

Interface work is priced by scope with a stated number and timeline. The drivers are message type or resource count, whether the interface is one-way or bidirectional, how cleanly the source system follows specification, how many downstream consumers exist, and how deep the validation requirement runs. Remediating an existing interface is frequently cheaper than organizations expect and delivers faster than a rebuild, which is why we assess before recommending replacement.