Healthcare Integration Developer — HL7, FHIR & Interoperability
I'm Matt Ratcliffe, a freelance software developer and architect working on healthcare interoperability from Ballarat, Victoria. I build and rescue the interfaces that move patient data between clinical systems — HL7 v2 messaging, FHIR APIs, and the integration engines that sit in the middle — for hospitals, health services and the vendors who sell to them.
What healthcare integration actually is
A hospital does not run on one system. Patient administration, pathology, radiology, theatre scheduling, pharmacy, billing and a long tail of departmental applications each hold part of the record, and each was bought at a different time from a different vendor. Healthcare integration is the work of making those systems agree: when a patient is admitted, every system that needs to know finds out, in the right order, without anyone retyping anything.
That work is unusually unforgiving. A dropped message in a retail system is a lost sale; a dropped message in a health service is a result that never reached a clinician. Most of what I do is less about protocol trivia than about making failure visible, recoverable and impossible to mistake for success.
HL7 v2 interfaces
HL7 (Health Level Seven) version 2 remains the workhorse of hospital messaging, decades after the standard was written. I build, migrate and troubleshoot interfaces across the message types that carry the day-to-day business events of a health service:
- ADT — admission, discharge and transfer
Registration, demographic updates, ward transfers and the patient movements most hospital interfaces are built around.
- ORM — orders
Requests for work: pathology, imaging, medication and other clinical services ordered by a clinician.
- ORU — observation results
The results that come back — laboratory findings, pathology and diagnostic observations.
- SIU — scheduling
Appointment booking, cancellation and rescheduling between scheduling and departmental systems.
- MFN — master file notification
Reference data: clinicians, departments, locations and services kept consistent across applications.
- DFT — detailed financial transaction
Chargeable services and procedures passed to financial systems for invoicing and claiming.
Typical engagements: standing up a new interface against a vendor's specification, replacing a brittle point-to-point mesh with an integration engine, adding a test environment that doesn't put production at risk, or working out why 10 of 12 messages arrive and nobody noticed the other two.
FHIR APIs
FHIR (Fast Healthcare Interoperability Resources) exposes the same clinical information as REST resources over HTTP and JSON, with familiar authentication. For new digital services it is dramatically easier to build against than HL7 v2. In practice most organisations run both: existing operational systems continue exchanging HL7 events while a FHIR facade serves modern applications. I build that facade, the transformation layer underneath it, and the reconciliation that proves both views agree.
Integration engines and transport
Interfaces rarely fail in the message format. They fail in the plumbing — retries that silently drop, queues that reorder, acknowledgements nobody reads, a certificate that expired on a Sunday. I work across integration engines and message transport with a bias toward observability: every interface I build can answer "did everything that was sent arrive, and how do you know?" without someone reading a log by hand.
Australian context
Working in Australian healthcare means more than the international standards. My Health Record, the ADHA conformance profiles, HL7 AU Base, national healthcare identifiers (IHI, HPI-I, HPI-O), secure message delivery, and the practice management systems that dominate primary care all shape what an integration can actually do. Add the Australian Privacy Principles and the handling requirements for health data, and integration design becomes a compliance question as much as a technical one.
How I work
I take on project work, ongoing retained support, and architecture and review engagements. That ranges from a single interface with a fixed scope, through to sitting alongside an in-house team as the person who owns interoperability decisions. I work remotely across Australia and internationally, and on site in Victoria where it helps.
Writing on healthcare interoperability
- FHIR vs HL7: Why the Future Is Taking Decades
Why a better standard has not displaced a working one, and what that means for integration planning.
- HL7 v2 Isn't Broken — So Why Replace It?
The case for and against migration, from someone who maintains both.
- Understanding ADT, ORM, MFN, DFT, SIU and ORU Messages Without the Jargon
An overview of the HL7 message types as business events rather than acronyms.
- Building Safe Integration Test Environments for HL7 ADT and SIU Interfaces
Why production should never become your test environment, and what to build instead.
- A Cancelled Record Still Needs To Say So
Handling voids and cancellations so downstream systems don't quietly keep stale data.
- Ten Out Of Twelve Is A Failure, Not A Result
Partial data loads are outages. Treating them as partial success is how interfaces rot.
Common questions
What does a healthcare integration developer do?
They build and maintain the interfaces that move clinical and administrative data between healthcare systems — mapping messages between formats such as HL7 v2 and FHIR, configuring integration engines, and making sure delivery is reliable, auditable and recoverable when something fails.
What is the difference between HL7 v2 and FHIR?
HL7 v2 is an event-driven messaging standard: a system publishes a message when something happens, such as a patient being admitted. FHIR is a REST API standard: systems expose resources such as Patient or Observation that others query over HTTP and JSON. HL7 v2 carries most day-to-day hospital traffic today; FHIR is generally used for newer applications and external-facing services, and the two commonly run side by side.
How long does it take to build an HL7 interface?
A straightforward one-way interface against a well-documented specification is usually a matter of weeks. Most of the elapsed time is not development — it is obtaining a specification, getting test environments and credentials from both vendors, agreeing message mappings, and validation testing. Bidirectional interfaces and anything involving patient matching take considerably longer.
Do you work with healthcare organisations outside Ballarat?
Yes. Integration work is almost entirely remote, and I work with clients across Australia and internationally. I am available on site in Victoria — Ballarat, Melbourne, Bendigo and Geelong — where it is useful to be in the room.
Can you work with our existing integration engine?
Usually, yes. The engine matters less than the discipline around it. I would rather work within the platform your team already runs and operates confidently than introduce another one nobody knows how to support at 2am.
Have an interface that needs building, migrating or rescuing? Tell me what you're working with — or read more about how I engage as a freelance developer in Australia.