Lock-in is a data question: the three exports to ask for before you sign

Hospital software vendor lock-in is a storage problem, not a contract problem. Three exports to demand before signing, and how to test them in a demo.

Most hospital software contracts in India already say the hospital owns its data. The clause is standard, the legal team approves it, and it settles nothing. Ownership is not access. A hospital can own eleven years of records and still be unable to read them without the vendor's help, which is the only form of lock-in that actually matters.

If you are an IT head searching for how to avoid hospital software vendor lock-in, the short answer is this: stop negotiating the exit clause and start testing the exports. Lock-in is not written into the contract. It is written into the storage format, the undocumented configuration tables and the decision history that was never designed to leave. The contract is reviewed once by lawyers. The format is lived with every day for seven years.

Why changing systems costs what it costs

Ask a colleague what the last migration actually consumed and you will usually hear the same shape of answer. The patient demographics and encounter data came across, more or less, with some reconciliation pain. What did not come across was everything that made the old system fit the hospital.

That is because a hospital system holds three different things, and they travel at very different speeds:

• Data. Patients, encounters, orders, results, bills, payments. Structured, high volume, and the part everyone plans for.
• Configuration. Tariff schedules and package rules, discount and approval matrices, bill numbering series, TPA-specific documentation requirements, department workflows, user roles. This is years of institutional decisions encoded in screens and tables, usually with no export path because nobody imagined exporting it.
• Decision history. Who approved the write-off, who overrode the credit limit, who changed the tariff and when. Increasingly, also: what the AI did, on what basis, and who let it.

Migration budgets are built around the first category. Migration overruns come from the second and third. Ospia's own commercial argument is that conventional hospital software costs compound exactly here — through customizations, multiple vendors, manual work, repeated integrations and a migration project every five to seven years. The rip-out is not an accident of a bad vendor choice. It is the business model working as designed.

The regulatory direction of travel is the other half of this. India's digital health programme is built on portable, consent-linked records rather than vendor-held ones; the ABDM programme's own FAQ sets out how ABHA-linked health records are meant to be shared with patient consent across participating facilities. A system that cannot hand your own data back to you is poorly placed to hand it to a patient on request either.

Export one: the clinical record, in a published standard, on demand

Ask for a full clinical and administrative extract in a documented, published format — FHIR R4 is the reasonable ask in 2026 — initiated by your team, not by raising a support ticket. The test is not whether the vendor says yes. It is whether they can show you the endpoint or the job, in the demo, against a sandbox.

Three follow-up questions separate the real answer from the polite one. Is the export complete or a subset. Is it rate-limited to the point of being theoretical. And is it available during the contract, or only on termination, which is precisely when relations are worst and leverage is lowest.

Export two: the configuration, not just the rows

This is the one almost nobody asks for and almost everybody pays for later. Ask whether the hospital can export its configuration — numbering, tariffs, approval matrices, pathways, role definitions — as readable, structured artefacts rather than screenshots and a consultant's memory.

If the only record of how your hospital works lives in a vendor's admin screens, you are not buying software. You are renting your own operating rules.

A good proxy question: was the configuration written down and signed off before the system was built, or discovered during go-live. Ospia's planning phase drafts configuration against the hospital's actual rules and requires sign-off before build, which is also what makes those rules an artefact that exists outside the application.

Export three: the audit and decision trail

Audit logs are usually treated as a compliance box. For NABH purposes they are. For lock-in purposes they are evidence that the system can explain itself to someone who is not the vendor.

If the system uses AI anywhere near money or medication, the bar is higher. Ospia publishes three tests for any AI vendor, and they are worth using even against us: can a decision from four months ago be replayed with its exact model, prompt version, inputs and output; can autonomy be set per task with an audit record; and can the AI provider be switched without a project. A system that fails the third test has moved the lock-in from the database to the model layer, where it is harder to see.

What to do before you talk to any vendor

None of this requires a purchase.

• Inventory what you already have: current data volumes, live integrations, every customization and the workflows that depend on them. Score each for how hard it would be to move.
• Write down your configuration yourself — tariffs, numbering, approval matrices — in a document you own. Do it now, while the people who decided those rules still work there.
• Add the three exports to your RFP as demonstrable requirements, not warranties. Demonstrated in a session you attend, on a date you pick.
• Ask your incumbent for export one this quarter. The answer tells you where you stand today, before any new contract is on the table.

Where Ospia fits

Ospia HOS is an AI-native hospital operating system rather than another hospital management system: a workforce of 12 governed AI agents, one patient record across 31 domains, and an autonomy dial from L0 to L4 that the hospital sets per task. It runs hospitals in production today.

On the specific question of exit, four things are concrete. Each hospital runs on its own database, with token-scoped services and Postgres row-level security keyed to the hospital context set per transaction. Residency is the hospital's choice — self-hosted on your own infrastructure, or managed cloud in-region, with sensitive AI task classes routable to a private model. Every use of personal data traces to recorded consent in a consent ledger that is consulted before use, which is also how DPDP compliance is designed in rather than bolted on. And the migration complexity assessment is handed over before signing rather than after, because a complexity map that arrives post-contract is a surprise, not an assessment.

What Ospia does not publish is worth stating plainly too. No customer count, no case studies, no total-cost-of-ownership savings percentage. Those are published as each hospital completes hypercare and agrees to be named. Any vendor claiming to win on every comparison line is selling rather than helping you evaluate, and that includes us.

If you want to see the exports rather than read about them, the executive demonstration runs forty-five minutes on synthetic data shaped like your hospital, with zero real patients. Bring your IT head and ask for all three.