The business case always prices the first interface
The build vs buy conversation usually starts with something specific. A results feed needs to reach the EPR, an ESR extract needs to drive access provisioning, a referral needs to land in a departmental system. The in-house team says it can build that in a few weeks, and on the evidence of the first interface it is right.
The business case is then written around that first interface: effort to build, cost of a licence avoided, time to value. What it rarely prices is the second year, when the developer who built it has moved on, a standards profile has changed, a new feed needs the same patient matching logic, and the first interface has quietly become a system the Trust owns and has to run.
That is the real question behind build vs buy in healthcare integration. Not which option builds the first interface more cheaply, but who carries the cost of everything that keeps running after it.
The three options, defined
- Build in house. The Trust's own team, or contractors working for it, writes and runs the integration logic: code, scripts, scheduled jobs, sometimes on top of a general purpose message broker. The Trust owns everything, including the maintenance.
- Buy point tools. Each problem gets its own product: one tool for the pathology feed, another for ESR, another for e-RS. Each is bought for a specific job and each brings its own supplier, contract, monitoring and way of working.
- Use an integration platform. One layer, configured rather than coded, where every flow is built, tested, monitored and changed in the same way. The supplier maintains the platform; the Trust owns its flows. What a healthcare integration platform actually is sets out what that layer has to do to earn the description.
Comparison table
| Build in house | Buy point tools | Integration platform | |
|---|---|---|---|
| First interface | Fast if the team is free | Fast for the problem the tool was bought for | Fast once the platform is in place |
| Standards and profile changes | Your team tracks and implements them | Each supplier, on its own timetable | The supplier, once, for every flow |
| Terminology releases | Your team imports and checks them | Handled per tool, if at all | Handled centrally |
| Monitoring and alerting | Built and maintained by you | One console per tool | One place for every flow |
| Security and assurance evidence | Produced entirely by you | Collected from every supplier | From one supplier, plus your own |
| Clinical safety (DCB 0129) | The Trust is the manufacturer | Each supplier, for its own product | The supplier, for the platform |
| Knowledge dependency | High; often one or two people | Spread across suppliers | Lower; flows are readable artefacts |
| Change latency | Depends on who is still on the team | Depends on each supplier's roadmap | A configuration change |
| Exit | You own the code, and its upkeep | One exit per supplier | Depends on portability: test it before signing |
| Best suited to | A small, stable estate with a durable team | One isolated problem with no neighbours | Many flows, frequent change, shared patterns |
Cost driver 1: people, and the knowledge they carry
The biggest cost of an in-house integration layer is not the build. It is that the knowledge of how it works sits with the people who built it.
That is manageable while they stay. It becomes the dominant cost when they leave, because an undocumented integration doesn't stop working when its author goes. It stops being changeable. The Trust keeps the capability and loses the option, which is the pattern we describe in the hidden cost of keeping a legacy PAS alive.
Point tools spread the dependency across suppliers rather than removing it. A platform reduces it most when flows are configured artefacts that someone who didn't build them can read.
Cost driver 2: standards and terminology that keep moving
HL7 v2 is stable. Almost everything around it isn't. FHIR profiles are revised, UK Core moves forward, national services change their interfaces, and SNOMED CT and the other code systems publish new releases on a regular cycle.
In a build, every one of those changes is a piece of work for your team, competing with every other priority. With point tools, each supplier absorbs the change on its own timetable, which is fine until two of them disagree. With a platform, the supplier absorbs it once, for every flow. Terminology server vs lookup table covers why terminology in particular punishes ad hoc handling.
Cost driver 3: monitoring and failure
An integration that works is invisible. An integration that fails quietly is expensive, and in healthcare the cost lands on a clinical team before it lands on IT.
In-house builds tend to under-invest here, because monitoring doesn't ship a feature. Point tools each bring a console, which means the on-call engineer checks four of them to answer one question. A platform puts every flow's history, failures and alerts in one place, so "where is this message now" is a lookup rather than an investigation. Point-to-point integrations vs an orchestration layer sets out how each architecture handles partial failure.
Cost driver 4: security, assurance and clinical safety evidence
Every integration that touches patient or workforce data needs evidence behind it: security controls, penetration testing, data protection documentation and, where it supports care, a clinical safety case.
When the Trust builds the system itself, it is the manufacturer of that system for the purposes of DCB 0129, as well as the deploying organisation under DCB 0160. That is a real, recurring workload, and it rarely appears in the build estimate. Bought products carry the supplier's manufacturer evidence, and the Trust's work becomes reviewing it rather than producing it.
Cost driver 5: change latency
The last driver is the one a board can see. When a clinical service asks for a new data flow, how long does it take to reach production?
In a build, the answer depends on who is still on the team and what else they are doing. With point tools, it depends on whether the request fits a tool you already have, or needs another procurement. With a platform, a new flow is a configuration change, tested before go live and versioned after it. Change latency is the clearest single measure of whether the integration layer is an asset or a constraint.
When building in house is the right call
It would be dishonest to present this as one-sided. Building is the right decision in real situations.
If the estate is small and stable, the team is durable and documents properly, and the integration needs are unusual enough that no platform fits well, then building is simpler and keeps control in the Trust. Some organisations also build deliberately to develop internal capability, and that is a legitimate choice when it is made knowingly.
The test is not whether the team can build the first interface. It is whether the Trust can staff, document and evidence the integration layer in its second and third years, through staff turnover and standards changes, without the knowledge leaving with the people.
Where WeHub fits
WeHub is the platform option in this comparison, so read this section with that in mind.
WeHub Studio is the integration layer: flows are configured rather than coded, tested with a sample message through every node before anything is live, and every run stays on record afterwards. WeHub Term handles terminology centrally, with official releases versioned and local code systems governed the same way. Your flows stay readable and portable, and workflows run on WeHub's environments or on your own infrastructure, depending on what your information governance requires.
If you are writing the business case now, price the second year for every option, including ours. Vendor lock-in in healthcare integration covers the exit tests to run before you sign with anyone.
