HEALTHCARE INTEGRATION · HL7 · FHIR
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.
DISEASE REGISTERS · CANCER REGISTER · CASE NOTES
We've spent a decade building and running the external interfaces of the National Cancer Screening Register — every connection from the central register to pathology labs, Medicare, OCR, mail house systems and the client portal. Registers at that scale teach you lessons that apply to every chronic disease register, at every scale. Three stand out.
1. The register is only as good as its inbound interfaces
A register's value is completeness and accuracy, and both are decided at the edges — where pathology results, claims data and correspondence enter the system. Interface engineering isn't plumbing around the "real" system; on a register, the interfaces are the system. Design them for validation, reconciliation and replay from day one, because the question is never whether a feed will misbehave, only when.
2. Identity is the hard problem
Matching records to the right person across pathology systems, Medicare data and self-reported details is where registers succeed or quietly fail. Deterministic matching alone won't cut it; you need probabilistic matching with clinical-safety guardrails and human review queues for the grey zone. This is precisely the problem HealthShare Patient Index exists to solve, and why we build with it.
3. Boring reliability beats clever features
A national register is infrastructure. Nobody thanks it for existing; everybody notices the moment a result is late. The engineering culture that keeps a register trusted is one of unglamorous discipline — monitoring, idempotent processing, graceful degradation, and maintenance as a first-class activity rather than an afterthought. It's why "design, build, deliver and maintain" is one sentence in our contracts, not two.
Scoping a register — cancer, chronic disease or screening? We've built the national one.
INTERSYSTEMS IRIS · SYSTEM INTEGRATION · PERFORMANCE
The call usually goes the same way: the application was fine at launch, it's crawling now, the vendor's answer is more hardware, and the invoice for that answer keeps growing. Before you buy another server, it's worth asking whether the architecture — not the capacity — is the constraint.
Where conventional stacks hit the wall
Most business applications are a relational database, an application layer, a caching tier, a message queue and an ETL pipeline — five products, five failure domains, and data copied between all of them. Every copy costs latency, licence fees and a new way to be inconsistent. Past a certain load, adding hardware just feeds the copying.
The consolidated alternative
InterSystems IRIS collapses that stack: a high-performance multi-model database, integration engine, and analytics in one platform, with data processed where it lives. For the systems we build on it, that consolidation is the performance strategy — fewer hops, fewer moving parts, dramatically lower total cost of ownership. It's the same platform trusted for national-scale health infrastructure, which is a reasonable stress test for any SME workload.
A pragmatic path, not a rewrite
None of this requires a big-bang migration. The pattern we use: identify the hottest constraint, move that workload to IRIS behind your existing interfaces, prove the gain, then expand by value. Simplest solution, most complex problem — in that order.
Benchmarking your options? Ask us for a straight assessment — including when IRIS is not the right answer.
