One Platform or Best-of-Breed? The Integration Bill Nobody Puts in the Quote

There are two ways to build a hospital's software estate and both have serious people arguing for them. Buy one platform that does everything adequately, or buy the best system in each category and connect them. The debate is old, it is not settled, and it is usually conducted with the wrong evidence.

The wrong evidence is feature comparison. Of course the specialist laboratory system has more depth than an HMS lab module; that is what specialisation means. The question was never whether it has more features. The question is what the connections cost, who maintains them, and what happens when one of them silently stops working on a Tuesday afternoon.

What is the actual difference between the two approaches?

An integrated platform shares one data model. A best-of-breed estate shares messages between separate data models.

That is the whole thing, and everything else follows from it.

In an integrated system, a patient exists once. When they are admitted, every part of the system knows, because there is nothing to tell. A dispense creates a charge because dispensing and charging are operations on the same data. There is no synchronisation because there is nothing to synchronise.

In a best-of-breed estate, a patient exists several times, once per system, and the copies are kept in agreement by messages. When the messages flow correctly, the experience is similar. When they do not, the copies diverge, and divergence in healthcare data is not a cosmetic problem.

Where does best-of-breed genuinely win?

Depth in a specialised domain, and negotiating leverage.

Some hospital functions are deep enough to sustain a serious independent software industry: laboratory, imaging, cardiology, oncology, pharmacy automation, operating theatre. A dedicated LIS from a vendor who does nothing else will handle analyser interfacing, quality control, reflex testing rules and NABL evidence in ways a general HMS lab module usually will not.

If a function is your hospital's primary business, buy the best system for it. A standalone diagnostic chain should own the best LIS it can afford. A dedicated imaging centre should own the best RIS-PACS. The specialisation is the business.

The second advantage is commercial. Multiple vendors means no single one owns your entire estate, and renewal conversations are different when the alternative is replacing one system rather than all of them.

Where does the integrated platform win?

Everywhere the data has to cross a boundary, which is most of a hospital's day.

The workflows that break in a best-of-breed estate are the boring ones that happen thousands of times a week:

• A consumable used in theatre reaching the patient's bill
• A discharge that has to wait for pharmacy, lab and billing to agree the patient is done
• A lab result that must be visible to a doctor who ordered it from a different system
• A consultant payout calculated from procedures recorded elsewhere
• A patient's complete record produced for a data request under DPDP
• An ABDM care context linkage that requires records from four systems

Each of these is solvable with integration. Each of them is also a place where, once a year, somebody discovers that a message queue stopped three days ago.

The cost of best-of-breed is not the interfaces you build. It is that you now own an integration estate, permanently, and integration estates need a named owner or they rot.

What does integration actually cost?

More than the quote, and the shape of the cost is predictable.

Every interface has a build cost, which is the part that gets quoted. It also has a test cost, which is larger than expected because the interesting cases are the exceptions: cancelled orders, merged patients, amended results, reversed charges. And it has a permanent operating cost: monitoring, reconciliation, and a person who understands it.

Then there is version drift. System A upgrades. The interface to system B was built against the old behaviour. Nobody notices until a report is wrong. Multiply by the number of interfaces and by the number of upgrades per year, and the reason hospitals with many systems employ integration engineers becomes obvious.

A rough planning assumption: budget for each interface roughly as an ongoing commitment rather than a one-time project, and count the interfaces before deciding. Six systems fully connected is fifteen possible pairs, which is why serious best-of-breed estates use an integration engine rather than point-to-point links.

How do you decide for your own hospital?

Four questions, in this order.

What is your core business? Specialise there, integrate the rest. A multi-speciality hospital's core is the hospital, not the lab.

What is your IT capacity? Best-of-breed with no integration owner is not a strategy, it is a deferred failure. If you cannot name the person who will monitor the interfaces, you have answered the question.

How many boundaries does your daily workflow cross? Count the cross-system steps in your ten most common workflows. If the count is high, integration is your dominant cost regardless of which systems you pick.

What is your migration position? An estate of separate systems can be replaced one at a time, which is genuinely lower risk. A platform is replaced all at once. If you are unsure about a vendor, the modular estate hedges better.

What if the decision is already made for you?

Most hospitals are not choosing from scratch. They have a system, some satellites, and a spreadsheet.

The useful move in that situation is not to pick a side but to reduce the number of boundaries where it hurts most. Identify the two or three cross-system workflows that consume the most staff time or leak the most revenue, usually charge capture and discharge, and close those. Consolidating three systems into one for a specific workflow is worth more than a strategy document about platform philosophy.

The other useful move is to insist that every new system, whatever it is, arrives with standards-based interfaces: HL7 or FHIR, DICOMweb for imaging, a documented API, and a real data export. A best-of-breed estate built on standards is manageable. One built on private integrations is a trap that took several years to build.

Where Kōami sits, and where it does not

Kōami is the integrated position, deliberately: hospital management, workforce, inventory, imaging, fertility and biomedical equipment on one identity and one data model, because the cross-boundary workflows above are where most hospitals lose time and money.

It is also built to be integrated with, not only integrated within, because no hospital estate is ever only one vendor. Standards-based interfaces, documented APIs and a clean export exist for the systems that will stay.

If your hospital's core business is a single specialised function, buy the best system for that function and connect it. If your hospital's problem is that six systems each hold a version of the same patient and none of them agree, that is the problem worth solving first, and it is not solved by adding a seventh.