HMS timelines: why they stretch into years — and how to shorten them

The mechanism behind HMS overruns, what to do before you buy, and the gated implementation model Ospia uses to keep time and scope honest.

Ask an IT head why a hospital software project ran long and the answer is rarely “the code wasn’t ready.” It is almost always scope that surfaced late: old customizations nobody catalogued, one-off integrations that break under load, numbering and tariff rules that live in someone’s head, or historical data everybody assumes will be migrated in full.

When these things appear after the contract is signed, two things happen. First, time slips while teams debate what is in scope. Second, costs stack up as vendors and hospital teams scramble to retrofit the plan. The result: a project that was supposed to take months drifts towards a year or more.

The mechanism: late discovery guarantees overrun

• Hidden customizations: years of tweaks embedded in the legacy HMS become visible only when users try to replicate them. Each one adds testing and training overhead.
• Brittle integrations: lab, pharmacy, finance, GST e-invoice, TPAs — if the interfaces are undocumented, migration exposes the gaps and edge-cases.
• Rule-work in people, not paper: numbering schemes, approval matrices, package and pathway logic exist, but are not signed as configuration before build starts.
• Data assumptions: free-text clinical notes, deep historical detail, legacy custom code and old audit logs are treated as “of course we’ll migrate this”, when each demands an explicit decision.

Overrun is not caused by migration alone. It is caused by discovering scope while you are already paying to deliver it.

What to do before you buy (even if you never call Ospia)

• Run a pre-signing assessment. Inventory current data, integrations, customizations and workflows and score them for migration complexity. Exit with a complexity map and a timeline you can defend.
• Draft configuration against your real rules. Numbering, tariffs, approval matrices, packages and pathways should be written down, reviewed and signed before any build.
• Make explicit migration calls. Flag free-text notes, deep history, legacy customizations and historical audit logs for explicit decisions: migrate, summarise or archive.
• Insist on gates. Name the implementation phases and require exit criteria for each. No parallel run without verified imports. No go-live while any gate is red.

If your current vendor will not do this pre-signing, do it yourself. The output — a complexity map, signed configuration, and a list of non-negotiable exit criteria — is the cheapest project insurance you can buy.

Where Ospia fits

Ospia positions itself as an AI-native Hospital Operating System, not another HMS. Our implementation method is deliberately gated: assessment, planning, data migration, parallel run, verification, training, go-live and hypercare — each with a documented exit criterion that must be signed before the phase closes. We give you the migration complexity assessment before you sign, draft configuration against your actual rules in planning, and our implementation tooling runs the configuration and migration checklists, validates data, and tracks readiness through go-live. Launch readiness must be proven rather than declared; no hospital goes live while any gate is red.

More on our approach to implementation: Implementation. How we decide what to migrate and what not to: Migration. For scope context versus clinic-first systems: Practo Ray vs Ospia.

What this changes for you

• You see surprises earlier, when they are cheaper to resolve.
• Your plan is written against your rules, with scope signed before build.
• Your parallel run has clear exit criteria, not an open-ended date.
• You keep the option to pause and say “not ready” — including when that is inconvenient for a vendor.