A hospital group running several branches, often in more than one country, reaches a point where the patient record, the operations data and the compliance evidence live in different systems per branch. The board asks for one platform. The CIO is handed a build-or-buy decision that is framed as binary and is not. This is how we advise groups to think about it, including where our own product, HMIS, fits and where it does not.
What 'build' really means for a hospital group
Building means owning the clinical core: patient index, registration and ADT, EMR, orders, pharmacy, billing, and the interoperability layer to lab analyzers, PACS and insurers. It means owning the regulatory surface in every country you operate in, and keeping it current as rules change. It means a permanent engineering organisation, not a project. Groups that succeed at this are usually large national chains with a technology subsidiary, a multi-year runway, and a reason the market cannot serve them: a payer model, a care pathway or a regulatory regime nothing off the shelf supports.
- Time to a usable system across all branches is measured in years, not quarters.
- The clinical safety burden, from medication five-rights checks to surgical checklists, is yours to design, test and evidence.
- Every integration to a lab analyzer, a PACS or a national registry is a project you fund.
- The upside is total fit and total control, and a platform that can become a commercial asset.
What 'buy' really means
Buying means adopting a platform's data model and workflows and configuring within them. The clinical core arrives tested. Interoperability is a matter of enabling interfaces rather than building them. The trade is fit: the platform's idea of a department, a tariff or a discharge is now yours, and changing it is a change request to the vendor. For a single hospital that is almost always the right trade. For a multi-country group it depends on one question: was the platform designed for a group, or for a hospital that happens to be sold to several?
The questions that decide it
- Is there a workflow, payer model or regulatory requirement that no available platform supports, and is it central enough to justify owning the clinical core? If yes, build. If it is peripheral, buy and extend.
- Do you operate in more than one country? If yes, the platform must enforce data residency per country and consolidate reporting across them, or you are building that part regardless.
- Do you have, or will you fund, a permanent engineering organisation? A build without one becomes an unsupported system within a few years.
- How fast do you need all branches on one patient record? Under two years favours buy.
- What is the exit? A platform you can take on-premise or into your own cloud reduces the lock-in that makes buy feel risky.
The third option: a group-designed platform with a vendor who extends it
Most groups need neither a bespoke build nor a take-it-or-leave-it product. They need a platform designed for a group hierarchy, deployed into their own infrastructure per country, and a vendor with an engineering bench that will extend it where the group's requirements are genuinely different. That is the position we built HMIS to occupy: group, country, branch and department in every record; one Master Patient Index with branch MRNs linked; per-country residency enforced at the infrastructure level; HL7 and FHIR for analyzers and PACS; and a modular architecture that can be rolled out branch by branch and extended by the same senior team that builds it.
The honest limits: HMIS is designed around groups, so a standalone clinic gains less from it. And a platform with a vendor bench is still a platform; if your requirement is a wholly different clinical model, you are in build territory and we would tell you so.
How to run the evaluation
- Write the group-level requirements first: patient identity across branches, credentialing across countries, consolidation, residency. Score every option against those before looking at departmental features.
- Insist on a working demonstration of the cross-branch scenarios with your own sample data, not a slide.
- Price the rollout per branch and per country, including interfaces, and compare that to the internal cost of building the same interfaces.
- Check the exit: can the system run in your cloud or data centre, and what does the data export look like?
- Pilot one branch, then one country, then the group. Any option that cannot be rolled out incrementally is the wrong one.
Whichever way the decision goes, the group that writes down its group-level requirements first makes a better one. Build if the market genuinely cannot serve you and you will fund the organisation to sustain it. Buy if a single-site product fits and you have one site. For a multi-branch, multi-country group, look for the platform that was designed for you and the bench that will grow with you.