One platform vs separate hospital and lab systems: the real cost of integration

A common path looks sensible on paper. You buy a hospital management system for the wards, the clinic, and billing, and separately you buy a laboratory system because the HMS lab module is thin. Two specialised tools, each good at its job. The quotes add up to a number you can defend. Then the project starts, and a third line item appears that was never on either quote: the integration between them.

That integration is where the real cost of the separate-systems approach lives, and it is easy to underestimate because it is invisible at the point of purchase. This piece is about sizing it honestly, so the comparison you make is the real one.

The seam is the product you forgot to buy

When the hospital system and the lab system are separate products, every piece of information that needs to move between them has to cross a seam. A doctor orders a test in the HMS; that order has to reach the lab system. The lab produces a result; that result has to travel back to the patient's chart. The bill for the test has to find its way to the cashier. None of that happens by itself. Someone has to build and maintain the connection, usually over a healthcare interface standard such as HL7 or FHIR.

With separate systems, integration is not a one-time task. It is a component you own, forever, with its own running cost.

That component has to be specified, built, tested, and then kept alive. When either vendor updates their software, the interface can break and has to be fixed. When you add a new test or a new workflow, the mapping between the two systems has to be extended. The integration is not a wire you connect once; it is a living part of your estate that needs attention indefinitely.

Where the cost actually shows up

The cost of the seam is spread across several places, which is part of why it is underestimated. It appears as:

• Build cost. The initial work to make two systems that were not designed together exchange data reliably.
• Maintenance cost. Ongoing effort to keep the interface working through updates on both sides.
• Reconciliation cost. Staff time spent checking that orders, results, and charges match across both systems, because two databases can always drift apart.
• Failure cost. The clinical and operational impact when the interface is down, a result that does not reach the chart, an order that does not reach the lab, a charge that never gets billed.
• Coordination cost. When something breaks, you are dealing with two vendors who may each point at the other.

Add these up over the years you will run the system, and the separate-systems option often costs more than the integrated one it appeared to undercut.

The hidden cost that is not money

Beyond budget, there is a quieter cost: two systems mean two versions of the truth. With separate databases, the patient's record is split. The lab system knows the results; the hospital system knows the visit. Keeping them perfectly aligned is a constant background effort, and the gaps are exactly where mistakes happen. A result attached to the wrong visit, a duplicate patient created because the two systems matched identities differently, a charge that exists in one place but not the other. These are not exotic failures. They are the ordinary friction of running care across a seam.

If you want the underlying distinction between the kinds of lab software involved here, our guide to LIS vs LIMS covers it; for clinical settings the relevant tool is a laboratory information system tied to patients.

When separate systems still make sense

This is not an argument that integration is always wrong. Sometimes you have a substantial existing investment you cannot replace yet, or a genuinely specialised requirement that no single platform meets. In those cases the integrated approach is not available, and a well-built interface is the right answer. The point is not to avoid integration on principle. It is to count its full, lifetime cost, and to do that before you sign, not after.

What one platform changes

When the hospital system and the laboratory live in one platform, sharing one patient record and one database, the seam disappears, and so does its cost. There is no interface to build because the order and the result are already on the same record. There is nothing to reconcile because there is one source of truth, not two. The doctor's order arrives in the lab without re-entry, the result returns to the chart they are already looking at, and the charge flows to the same bill, automatically.

This is the choice Veona is built around. The laboratory is not a separate product you license and connect; it is part of the platform, on the same record as registration, charting, the pharmacy, the wards, and billing. That removes an entire category of cost, build, maintenance, reconciliation, and failure, that the separate-systems route carries by design.

If you are comparing options, our Veona Labs overview shows the built-in laboratory in detail, the platform overview shows how the modules share one record, and our buyer's checklist puts integration cost alongside the other questions worth asking.

The takeaway: when you compare a single platform with separate systems, do not compare the licence quotes. Compare the licence quotes plus the lifetime cost of the seam. That is the comparison that tells you the truth.