How to Run a Healthcare Integration Platform Comparison That Survives Contact With Your Trust

Six months after the contract was signed, the integration platform that won the procurement is the one nobody wants to own. It demoed beautifully. The scorecard had it ahead on every axis. And now the team is writing custom transforms by hand because the connector that was "ESR-ready" turned out to mean it could read a file, not reconcile against live entitlement state.

This is the gap that no healthcare integration platform comparison captures well: the distance between what a platform can do in a controlled demo and what it costs you to run in a live Trust environment, against real ESR feeds, real Spine reconciliation, and real IG scrutiny. The platforms all look capable when someone else is driving. The differences only show up when your team is on call at 2am for a payroll file that loaded 4,790 of 4,800 rows.

This piece is for the IT Lead, integration architect, or CTO who is past the "do we need this" stage and into "which one, and how do we defend the choice." The aim is to give you a comparison method that holds up after the signatures dry.

The shortlist that looked identical on paper

You know the procurement pack. Five vendors, a weighted scoring matrix, columns for "FHIR R4 support," "NHS Spine connectivity," "HL7v2 handling," "security accreditation," and a price. Every vendor ticks every box. The matrix produces a winner by a margin of four points, most of which came from a slick UI demo and a confident answer about roadmap.

The problem is that the matrix measured capability claims, not operational reality. "Supports FHIR R4" is true of almost everything now. It tells you nothing about whether the platform can handle a Trust's actual non-conformant HL7v2 feed, the one with the local Z-segments that the previous integration engine had thirty years of hand-tuned mappings for.

The healthcare integration platform comparison that matters is not a feature checklist. It is an assessment of how the platform behaves under the specific conditions your Trust will put it under, and how much of your team's time it consumes to keep running. Those two things rarely appear on the scorecard, because vendors compete on the first kind of question and live with the second.

Why most integration platform comparisons measure the wrong things

Feature parity is now the baseline, not the differentiator. Any serious platform in the NHS market will claim FHIR R4, HL7v2, MESH transport, and some form of Spine and PDS connectivity. Scoring these as if they discriminate between vendors wastes the most valuable column in your matrix.

What actually separates platforms is harder to see in a demo:

1. How non-conformant data is handled. Real NHS data is messy. Trusts run feeds with local segments, inconsistent date formats, and historical quirks. A platform that assumes clean, spec-compliant messages will pass every demo and fail on your first production batch. The question is not "does it support HL7v2" but "what happens when a message is almost but not quite valid."2. What partial failure looks like. When a 4,800-row absence file loads 4,790 rows and rejects 10, does the platform tell you, retry the 10, and surface them for review? Or does it report the job as green and let the missing rows become a payroll dispute six weeks later? Row-level versus job-level failure handling is invisible in a demo and decisive in production.3. The cost of change. Every Trust integration changes. A new EPR, an ESR configuration shift, a FHIR profile update. The real cost of a platform is not the initial build, it is what each subsequent change costs in your team's hours. Some platforms make change a config edit. Others make it a project.4. Who can operate it. A platform that only your one contractor understands is a risk, not an asset. The honest comparison question is whether a mid-level member of your existing team can own a workflow after the implementation partner leaves.

None of these fit neatly into a weighted score. All of them predict whether you will still be happy in eighteen months.

The criteria that actually predict success

If you are building a healthcare integration platform comparison framework, weight it toward the criteria that correlate with long-term outcomes rather than demo performance.

Operability under real data. Ask for a proof of concept using a sample of your own messy data, not the vendor's clean sample. This single change exposes more than any other part of the evaluation. A vendor confident in their platform will welcome it. A vendor who resists is telling you something.

Observability and reconciliation. Can the platform show you, at field level, what came in, what was transformed, and what was written? This is the difference between answering an IG or DSPT question in ten minutes and spending a week reconstructing what happened. Field-level audit is not a nice-to-have in an NHS context, it is the thing that makes DCB 0129 and 0160 conversations short.

Failure transparency. How the platform behaves when something breaks matters more than how it behaves when everything works. Look for row-level error handling, automatic retry with backoff, dead-letter visibility, and alerting that distinguishes a partial failure from a total one.

Change velocity. Estimate the cost of a representative change: adding a new feed, modifying a transform, onboarding a new system. Ask each vendor to scope the same change and compare the answers. The spread will be wide and revealing.

Operational ownership. Map who runs the platform day to day after go-live. If the answer is "the vendor" or "one specialist contractor," your total cost and your risk are both higher than the licence fee suggests.

Accreditation and data residency. Confirm current security posture and where data physically sits, especially for any cloud component. This is a verify-don't-assume area: ask for the current state in writing rather than relying on a marketing page.

The questions a demo will never answer for you

A demo is designed to show the platform at its best. To run a comparison that survives implementation, ask the questions the demo is structured to avoid:

1. Show me what happens when a malformed message arrives. Not a description, the actual behaviour.2. Walk me through your last three customer incidents and how they were resolved. The pattern of failure tells you more than the feature list.3. How long did your most recent NHS implementation actually take, versus the estimate at contract signing?4. When a customer wants to leave, how do they get their workflows and transforms out? Lock-in is a cost even if you never exercise it.5. Who at our Trust will be able to operate this without you, and how long does it take them to get there?

The answers separate vendors who sell capability from vendors who deliver outcomes. The second group answers these comfortably. The first group reframes the question.

Build, buy, or middleware: framing the real decision

Before comparing platforms against each other, it is worth being honest about whether a platform is the right shape of answer at all. There are three broad routes, and the comparison only makes sense once you have chosen the route.

Building point-to-point integrations in-house gives you total control and total ownership cost. It works when you have one or two stable interfaces and strong internal engineering. It scales badly: every new system multiplies the connections you maintain, and the knowledge tends to live in one person's head.

Buying a single-purpose connector solves one problem cleanly but leaves you managing a collection of unrelated tools, each with its own failure modes and none of them reconciling against each other.

Adopting an integration platform, an iPaaS built for healthcare, trades some control for a consistent model: one place to build, monitor, and reconcile across ESR, Spine, PDS, e-RS, and clinical systems. The trade is worth it when you have several integrations to run and you want operational consistency rather than a museum of bespoke scripts. WeHub sits in this category, built specifically for NHS systems rather than retrofitted from a generic enterprise iPaaS, which matters precisely because of the non-conformant-data and reconciliation problems above.

The decision you are actually making is not "which platform is best." It is "which route fits our scale, our team, and our risk appetite," and only then "which platform executes that route well."

A scoring framework you can take into procurement

Here is a comparison structure weighted toward operational reality rather than feature claims. Adjust the weights to your context, but resist the urge to let capability checkboxes dominate.

1. Operability under real data (25%) - proof of concept on your own messy sample, not theirs.2. Observability and field-level audit (20%) - can you reconstruct any record's journey for an IG query.3. Failure handling and transparency (15%) - row-level errors, retry, alerting that distinguishes partial from total failure.4. Change velocity and total cost of ownership (15%) - scoped cost of a representative change, not just the licence.5. Operational ownership and skills fit (10%) - can your existing team run it.6. NHS-specific connectivity, proven not claimed (10%) - references for live ESR, Spine, PDS, e-RS integrations of your type.7. Security, accreditation, data residency (5%) - current state confirmed in writing.

Feature parity items like "supports FHIR R4" belong inside criterion six as evidence, not as their own weighted columns. If a platform cannot show a live NHS reference for the integration type you need, no amount of demo polish should compensate.

The bottom line

The platform that wins your comparison should be the one that costs your team the least to run when something goes wrong, not the one that demos the best when everything goes right. Those are different platforms more often than procurement processes admit.

If you do one thing differently in your next healthcare integration platform comparison, make it this: insist on a proof of concept using a sample of your own real, messy production data, scored on how the platform handles the parts that are not quite valid. That single test predicts more about the next eighteen months than the rest of the scorecard combined. Run that first, and the right choice usually makes itself obvious.