Clinical interoperability
HL7 v2 or FHIR: choosing an integration approach
Compare message-based clinical interfaces and FHIR APIs, then choose an approach based on the workflow and the capabilities your systems actually expose.
By Globalesm
HL7 v2 and FHIR both support healthcare data exchange. The useful question is which exchange your source and destination can support for a particular workflow. An integration may need both.
Where HL7 v2 fits
HL7 v2 commonly supports event-driven messages such as admissions, orders, and results. Implementations can differ in their message profiles and local fields. For an existing interface, ask for the actual specification and representative messages, including acknowledgments and rejection examples.
Where FHIR fits
FHIR organizes clinical information into resources and supports REST APIs alongside messaging, documents, and other exchange patterns. An available FHIR endpoint does not establish that every required resource, operation, or field is supported. Check the implementation's version, profiles, supported operations, authorization requirements, and access process.
Use the workflow to make the decision
For a discovery session, we recommend answering these questions:
- What event starts the workflow, and how quickly must data arrive?
- Which records, identifiers, and changes must the destination receive?
- What interfaces does each vendor actually make available to this customer?
- How will errors, updates, duplicates, and missing records be reconciled?
Plan the mapping when both are needed
A bridge between v2 messages and FHIR resources needs explicit mapping rules. Preserve the business meaning of identifiers, codes, timestamps, and corrections. Document what cannot be represented or supplied, then test representative scenarios with the receiving team. The deliverable should include the mappings and operational behavior, not only a working connection.
Put the plan into practice
Tell us which systems you need to connect and where you need help.