A hospital information system stores records. Ask what your system is accountable for.

Most HIS evaluations in India compare feature grids. A better test for an IT head: what does the system do without a person, and who approved it.

If you are the IT head of a hospital in India, the phrase “hospital information system” has probably appeared in every tender document, every board note and every vendor deck you have read in the last decade. It is worth reading the words slowly. Information, and a system to keep it in. The category named itself after storage.

And storage is largely what hospitals got. The system holds the admission, the discharge summary, the bill, the claim file, the stock register, the OT schedule. It holds them accurately. It holds them in one place, more or less. What it does not do is any of the work.

So the work went elsewhere. It went into the billing executive who reconciles the TPA portal against the system by hand. Into the WhatsApp group where the OT list is actually confirmed. Into the Excel file the pharmacy in-charge keeps because reorder levels in the system were set at go-live and never revisited. Into the month-end scramble where someone pieces together why realisation is down. The system recorded all of it faithfully, afterwards.

Why the HIS model produces this

This is not vendor incompetence. It is the design intent of the category, followed honestly to its conclusion.

A hospital information system is built as a system of record. Its unit of value is the stored, correct, auditable row. Its user interface is a set of screens for humans to type into. Its internal model of a hospital is a set of forms, and its internal model of a hospital employee is a typist. Judged on its own terms, a good HIS succeeds completely — and leaves every operational decision exactly where it found it.

Two consequences follow, and both land on the IT head rather than on the vendor.

The first is that the gap between what the system stores and what the hospital needs is closed by customization. Each closure is reasonable in isolation. Together they produce the cost structure that conventional hospital software is actually built on: customizations that must be re-done on every upgrade, multiple vendors for the parts the core never covered, manual labour where neither vendor reaches, integrations rebuilt whenever one side changes, and a migration project every five to seven years when the accumulated weight makes the next upgrade impossible.

The second is that nobody can be held to anything. You can hold a vendor to uptime. You can hold a vendor to a support response time. You cannot hold a filing cabinet to a claims rejection rate, because filing cabinets do not submit claims. The accountability sits with your staff, and your staff are working inside a system that was never asked to help them decide anything.

The test, before you buy anything

You can run this exercise this quarter with no procurement, no pilot and no budget line. It is more useful than most vendor demonstrations.

• List the ten tasks that consume the most staff hours in your hospital. Not modules. Tasks. Pre-authorisation follow-up, discharge bill assembly, indent approval, duty roster changes, claim short-payment reconciliation.
• Against each one, mark whether your system does it or records it. Be strict. “Generates a report someone reads and then acts on” is recording.
• For each task the system records, write down who is accountable and what their escalation path is. You will usually find a name and no written path.
• Ask what happened, not what is stored. Pick one bill from four months ago and try to reconstruct who changed what, when, and under whose approval. If you cannot, your audit trail is thinner than your NABH file suggests.
• Test the exit before you test the entry. Ask your current vendor for a full export of your own data in a standard format, and time how long it takes to arrive. The answer tells you your real switching cost, and it is the number your promoter will care about in year six.

Do this and your next evaluation changes shape. The feature grid stops being the document. The questions that matter become: what does this system do without a person, how far can it go before a human is required, and can you show me what it did and who allowed it.

Where Ospia fits

Ospia HOS is positioned deliberately outside the HIS category — an AI-native hospital operating system rather than another hospital management system. The difference is the one above. One patient record across 31 domains, so there is no integration project between the parts. And a digital workforce of twelve AI agents — admission, billing, claims, pharmacy, inventory, OT coordinator, ICU assistant, finance, HR, CEO, support and implementation — each with an identity, a scope, permissions, tools, KPIs and an escalation path. Governed the way you would govern a new hire, because that is what accountability requires.

Concretely: the Inventory Agent learns reorder levels from real consumption and supplier lead times and raises orders inside your approval matrix. The Support Agent answers staff questions against live system state and escalates with the evidence already gathered. The Implementation Agent runs configuration and migration checklists, validates data and tracks readiness through go-live.

How far any of them may go is not our decision. Autonomy is a maturity ladder with five levels — L0 manual, L1 system-assisted, L2 AI-recommended, L3 human-approved AI execution, L4 autonomous within approved policy — set per task and held by the hospital. Action risk classifies the action; autonomy maturity configures how far automation may currently go for it at your hospital. The two are orthogonal on purpose. Above L2, execution requires a named human. At L4, it requires a policy you approved, and every run still produces a replayable ledger entry, an event trail and a reversal path. The level shown for each agent is a starting point, and raising or lowering it is an audited decision with a name attached. No agent can act outside the task registry or above the level you configured.

For an IT head, three more things matter. The system is complete with no external AI configured at all, using deterministic fallbacks for assistive paths, so AI is never a dependency for the hospital to keep running. Deployment is self-hosted on your own infrastructure or managed cloud, your choice. And everything is exportable over an open FHIR R4 API, with the full event history belonging to you — every event is retained permanently, so the outbox is also the event store and your hospital's history. Leaving should be as open as arriving.

All eight phases of the build, P0 through P7, are complete, under a written engineering charter where nothing merges without passing the full gate ladder. The clinical core is live in hospitals today. What we are still building toward is the part of the argument that is a goal rather than a result: that as a hospital's needs grow, the operating system identifies them and extends itself on the platform already running, with no scheduled rip-and-replace.

What we will not claim

We publish no customer count, no hospital names and no case studies. Those are published as each hospital completes hypercare and agrees to be named, and not before. We publish no total-cost-of-ownership savings percentage either. We would rather model it against your own volumes, licence and support spend, customization history and integration count than hand you a generic figure.

If the accountability test above produced an uncomfortable list, two next steps are open. Run the revenue leakage calculator against your own numbers — it is the business-case tool that is available today. Or take the executive demonstration: forty-five minutes, run on synthetic data shaped like your hospital, zero real patients.