Every healthcare integration project we scope eventually lands on the same question: should this interface be HL7 v2 or FHIR? The honest answer, after 35 years of connecting healthcare applications, is that it’s usually the wrong question.
The right question is: what do the systems on each end of this connection actually speak? Australian pathology, hospital and GP systems overwhelmingly speak HL7 v2 today, and will for years yet. FHIR is the clear standard for new APIs, patient-facing portals and app ecosystems — and it’s where the Australian Digital Health Agency is steering national infrastructure. Both facts are true at once.
The pattern that works
The architectures that survive in production treat v2 and FHIR as coexisting layers, not competitors. Keep the v2 feeds that already work — they’re battle-tested and your trading partners depend on them. Expose FHIR where consumers need modern APIs. Put clean, terminology-aware translation between the two, and centralise it in one integration layer rather than scattering conversion logic through every application.
This is exactly what platforms like InterSystems IRIS for Health are built for: v2 messaging, FHIR resources and terminology services in one engine, so the translation layer is configuration and code you control — not a fragile chain of point solutions.
The mistake to avoid
The expensive failure mode is the “big bang FHIR migration” — ripping out working v2 interfaces because FHIR is newer. We’ve been called in to rescue more than one of these. Interoperability standards are a means to reliable clinical data flow, not an end. Modernise where FHIR adds capability; leave working infrastructure working.
Facing this decision on a live project? Talk it through with us — the first conversation is free and jargon-optional.