Choosing a Healthcare Integration Engine: What Actually Matters (Past the Demo)

The Questions That Should Drive Your Evaluation (Before the Demo)

Vendor demos are optimised for vendor demos. The scenarios are clean, the data is tidy, and the presenter knows exactly which workflow to avoid. Useful evaluation happens before the demo — in the questions you put on the table and the evidence you require in response. These are the questions that actually separate platforms in a healthcare context.

HL7 v2 Processing

Ask how message validation, transformation, and routing are handled natively. Then ask to see real HL7 edge cases handled — not clean ADT A01 messages from a training environment. Ask what happens with non-standard Z-segments, with OBX-5 carrying encoded values, with MSH-3 values that downstream systems use for routing. Ask what the transformation language looks like and who on your team will maintain it.

FHIR Support

"FHIR-enabled" covers a wide range of actual capability. Ask for the FHIR capability statement. Ask which resource types are supported for read, search, and write. Ask what conformance level the FHIR server actually meets — and ask for evidence, not a slide. The gap between "we support FHIR R4" and "we expose a production-grade FHIR R4 server at IHE MHD conformance level" is significant and relevant to most NZ health integration programmes.

Monitoring and Observability

What does operations look like on a bad day? Ask for a demonstration of how the platform surfaces a feed that has stopped processing silently. Show you what the on-call person sees at 2am when messages are queuing but not failing. Ask how you distinguish between a connectivity failure, a message parsing error, and a downstream system rejection — and how quickly each type of issue can be isolated from the monitoring tooling alone.

Upgrade and Patching Model

Who controls the upgrade schedule? How often do major version upgrades happen, and what is the realistic testing burden on your team per upgrade? For on-premise installations, what does a major version upgrade require in terms of environment downtime, interface regression testing, and vendor support involvement? For cloud-hosted platforms, who controls the timing and what notification window do you get before changes are applied?

Staff Capability Requirements

What does it actually take to build and maintain interfaces on this platform — in terms of training, certification, and ongoing expertise? Is that capability available in your local market? What happens when the person who knows the platform leaves? Ask vendors for an honest answer to what the staffing model looks like for a production estate of your size.

Platform-by-Platform View

No platform is universally the right choice, and the market has become more complicated as acquisitions and cloud migrations change what products actually are versus what they were when your team last evaluated them. This is an honest summary of where each major platform currently sits for NZ healthcare environments.

InterSystems HealthShare / IRIS for Health

Strengths: Deep HL7 v2 handling that has been production-tested in NZ and UK public health for decades. Direct TrakCare integration that no other platform matches natively. Comprehensive FHIR R4 support with a production-grade FHIR server. Strong monitoring and operational tooling. HealthShare Connect Cloud reduces infrastructure overhead for organisations moving off on-premise installations.

Considerations: Licensing cost is significant — the total cost of ownership is higher than most other platforms before you factor in staffing. Requires dedicated staff with InterSystems training; generic integration developers are not enough for a production estate. Upgrade cycle management for on-premise installations is a real operational burden that organisations frequently underestimate until they are in it. The platform rewards investment: organisations that staff and fund it properly get strong outcomes; those that don't accumulate technical debt quickly.

MuleSoft (Salesforce)

Strengths: Strong enterprise API management and integration governance tooling. Modern developer experience that appeals to organisations with existing software engineering capability. Good fit for organisations with complex API strategy and multiple integration use cases that extend beyond healthcare — particularly where Salesforce is already in the stack.

Considerations: Native HL7 v2 support is less mature than InterSystems or Rhapsody — it requires additional connectors and more custom configuration to handle the edge cases that appear routinely in clinical messaging environments. High cost, particularly when API call volumes and runtime scale. Significantly better suited to API-first integration estates than to traditional clinical messaging environments with large HL7 v2 interface estates. If HL7 v2 is your primary integration challenge, MuleSoft is not the natural starting point.

Azure Integration Services / Logic Apps

Strengths: Cloud-native with low infrastructure overhead for organisations that are already heavily invested in Azure. Excellent Microsoft ecosystem alignment — strong fit where Microsoft 365, Azure AD, and Dynamics 365 are central to the estate. Licensing can be more accessible than dedicated healthcare integration platforms, and operational overhead is lower for simpler integration use cases.

Considerations: Limited native HL7 support without third-party tooling. Azure Health Data Services (the successor to Azure API for FHIR) provides FHIR capability, but clinical HL7 v2 messaging use cases require considerably more configuration than purpose-built healthcare engines. Logic Apps is well-suited to orchestration and API integration; it is less well-suited to high-volume, low-latency clinical message processing with complex transformation requirements. Best positioned as part of a broader Azure estate rather than as a standalone clinical integration platform.

Rhapsody / Rhapsody Cloud (Inperia)

Strengths: Strong HL7 v2 heritage with a purpose-built clinical messaging architecture. Established presence in NZ and Australian hospital environments — familiar to many NZ integration teams, which is a genuine operational advantage when hiring and when engaging external support. The interface design model is accessible to clinical informaticists as well as developers.

Considerations: The Rhapsody Cloud migration timeline and support model have changed following the Inperia acquisition, and organisations evaluating Rhapsody should assess the current product roadmap and support commitments carefully rather than relying on the platform's pre-acquisition reputation. The ecosystem for NZ-specific platform integrations (particularly TrakCare) is smaller than InterSystems. Vendor stability in a consolidating market is a legitimate evaluation criterion.

What the RFP Process Gets Wrong

Most RFP processes for integration engine selection are structured around the wrong questions. The result is evaluations that score vendors highly on criteria that look good in a presentation and miss the factors that determine whether the platform works well in your environment over a five-year period.

• Evaluation criteria that favour demo capability over operational reality. Scoring a vendor highly because they demonstrated a smooth message transformation in a pre-configured environment tells you little about what happens when your interface estate is handling 50,000 ADT messages a day with Z-segment dependencies that were never documented. Weight operational evidence — production reference sites with estates similar to yours — more heavily than demo performance.
• Reference checks that don't ask about failure scenarios. Every vendor reference will confirm the platform works. The useful question is: what has broken, and how long did it take to fix it? What was the experience of going through a major upgrade? What would you do differently in the evaluation if you were starting again? Reference calls that only elicit positive responses are not providing useful signal.
• TCO calculations that miss the major cost drivers. A TCO model that includes licensing and infrastructure but omits staff time, training and certification costs, upgrade testing burden, and interface documentation effort is systematically underestimating the real cost — often by a factor of two. The largest cost driver for a complex integration estate is not the platform licence. It is the ongoing staff time required to build, maintain, and support the interfaces. Any TCO model that doesn't include this is not a real TCO model.

The Decision Framework

Standardise on One Engine vs Accept a Heterogeneous Estate

Standardisation on a single integration engine is the right long-term goal for most organisations, but it is often not the right immediate decision. If you already have a functioning InterSystems estate and a separate MuleSoft deployment managing API integrations, replacing one to achieve homogeneity has a cost — in migration effort, in disruption, and in lost expertise — that needs to be justified by a concrete operational benefit, not just architectural elegance.

The case for a heterogeneous estate is strongest when the platforms serve genuinely different integration patterns: a clinical messaging engine for HL7 v2 feeds alongside an API gateway for modern REST/FHIR integrations. The case weakens when the heterogeneity is accidental — the result of separate teams making separate decisions — and produces operational fragmentation without corresponding benefit. Decide whether your heterogeneity is intentional and managed, or inherited and expensive.

Cloud-Hosted SaaS vs On-Premise

The cloud vs on-premise decision is not only a cost decision. On-premise gives you direct control over upgrade timing, environment configuration, and data residency — which matters in some NZ health contexts. Cloud-hosted platforms reduce infrastructure overhead and shift upgrade responsibility to the vendor, but you give up control over when changes happen and what they affect.

The honest question is not "is cloud cheaper?" — it depends heavily on your existing infrastructure. The question is: does your team have the operational capability to run on-premise infrastructure well? A poorly-run on-premise deployment accumulates more risk than a well-run cloud deployment, regardless of cost. Conversely, if your governance, security, and data residency requirements create significant complexity for cloud deployment, that cost belongs in the comparison too.

Vendor Stability in a Consolidating Market

The healthcare integration platform market has been consolidating for a decade, and that trend is continuing. When evaluating platforms, vendor stability deserves explicit weight. The question is not whether the vendor will disappear — most won't — but what happens to your platform, your support model, and your upgrade path if the vendor is acquired.

Evaluate the vendor's ownership structure, the strategic fit of the product within any parent company, and the history of product investment following previous acquisitions. Ask vendors directly what their roadmap looks like over the next three years and what the contractual commitments are if the product is discontinued or substantially changed. This is not a niche concern — it is standard practice for any platform decision with a five-to-ten year dependency horizon.

Frequently Asked Questions