Hospital Software Contract: 15 Clauses to Negotiate

Hospital software deals rarely go wrong on signing day. They go wrong in year three. The renewal quote arrives with a 25% increase. The scheme portal changes its format and the vendor calls the fix a "change request". A new CFO asks for a full data export before evaluating alternatives and is told it will take three months and cost extra. None of this was hidden. It was simply not written into the contract.

This article is for the owner, CFO or legal counsel signing a hospital software agreement. It lists fifteen clauses worth negotiating, explains why each matters in hospital reality, and gives plain-English sample wording to discuss with your lawyer.

This is not legal advice. The sample wording is a starting point for a conversation with your advocate, not text to paste into a contract.

Why do hospital software contracts fail in year three?

Because the first contract is negotiated around go-live, and most of the risk arrives after it. In year one everyone focuses on the implementation. By year three the hospital depends on the system for every bill, claim and discharge, and leverage has shifted to the vendor. Switching costs are high and both sides know it.

The fix is to negotiate the year-three questions in year zero: what it will cost to stay, what it will cost to leave, and what happens when the law or a scheme changes. Our guide to switching hospital software covers the exit project itself. This article is about making sure the contract allows it.

Data ownership and exit

1. Data ownership

The contract should state that the hospital owns all data it enters or generates, including derived reports, and that the vendor uses it only to provide the service.

Sample wording: "All data entered into or generated by the System for the Hospital, including patient, clinical, financial and operational records, is the property of the Hospital. The Vendor shall process such data only to provide the Services and on the Hospital's documented instructions."

2. Data export on demand

Do not wait until exit to find out whether export works. Ask for a complete export in a documented, machine-readable format at any time, within a fixed number of days, at no extra charge at least once a year.

Sample wording: "On written request, and in any case on termination, the Vendor shall provide a complete export of the Hospital's data, including attachments and audit logs, in a documented, non-proprietary format within 15 working days, with a data dictionary."

3. Transition assistance

Ask for a defined period after termination during which the system stays available in read-only mode and the vendor supports migration at agreed rates.

Sample wording: "For 90 days after termination the Vendor shall keep the System available in read-only mode and provide reasonable migration assistance at the rates in Schedule X."

4. Escrow or continuity

For on-premise software, source code escrow with release triggers (insolvency, end of support) protects you. For cloud software, a data escrow or guaranteed periodic export to the hospital's own storage is usually more useful.

Sample wording: "The Vendor shall deliver a full encrypted backup of the Hospital's data to storage controlled by the Hospital at least weekly."

Service levels that actually pay out

5. Uptime with automatic credits

An uptime promise without a measured definition and automatic credits is a hope. Define the measurement window (per calendar month), what counts as downtime (core modules unavailable to users), and what is excluded (only pre-announced maintenance outside clinical peak hours).

The arithmetic matters. In a 30-day month (720 hours), 99.5% uptime allows about 3.6 hours of downtime; 99.9% allows about 43 minutes. An illustrative credit ladder:

• Below 99.5%: 5% of the monthly fee
• Below 99.0%: 10%
• Below 98.0%: 20%, and a right to terminate if this happens in any three months of a twelve-month period

Sample wording: "Service credits apply automatically and are deducted from the next invoice without the Hospital having to claim them."

6. Support response and resolution by severity

Hospitals run at night. Define severity levels in hospital terms ("billing or admission cannot proceed" is Severity 1), with 24x7 response for Severity 1 and named escalation contacts.

• Severity 1: response within 30 minutes, workaround within 4 hours, 24x7
• Severity 2: response within 2 hours, resolution within 2 working days
• Severity 3: response within 1 working day

These are illustrative targets. What matters is that they are written, measured and reported monthly.

Price, scope and change

7. Price escalation cap

Cap annual increases for the full term and for renewals. The difference compounds. Illustrative: on ₹6 lakh a year, an uncapped 10% annual increase costs about ₹36.6 lakh over five years; a 5% cap costs about ₹33.2 lakh, a difference of roughly ₹3.5 lakh.

Sample wording: "Fees may be increased once a year by no more than 5% or the change in CPI, whichever is lower, including on renewal."

8. Scope and counting rules

Define the modules included and how fees are counted: beds (operational or licensed?), users (named or concurrent?), sites. Ambiguity here is where surprise invoices come from. Our hospital software cost guide explains the common pricing models.

9. Acceptance testing and go-live sign-off

Tie payments to acceptance, not to calendar dates. Define acceptance as passing agreed test scripts with your own data (a full admission-to-discharge cycle, a cashless claim, a pharmacy issue, a month-end report) and a defined period of stable live use.

Sample wording: "The Go-Live milestone payment is due only after the Hospital signs the acceptance certificate following 30 days of live use with no open Severity 1 defects."

10. Change requests and customisation

Agree a rate card for changes in advance, and a rule that the vendor quotes before starting work. Define what counts as a defect (free) versus an enhancement (paid).

11. Statutory and scheme updates included

This is the clause hospitals most often miss. GST rate changes, scheme claim formats, IRDAI or NHCX requirements, ABDM changes and statutory payroll rules change regularly. The contract should say that changes required by law or by a payer the hospital already works with are part of the subscription.

Sample wording: "Updates required to keep the System compliant with Indian law, and with the claim formats of payers listed in Schedule Y, are included in the Fees."

Sub-processors, hosting location and DPDP

12. Data protection terms

The Digital Personal Data Protection Act, 2023 will make the hospital the data fiduciary and the software vendor, usually, a data processor. Section 8(1) keeps the fiduciary responsible for processing "on its behalf by a Data Processor", "irrespective of any agreement to the contrary". Section 8(2) allows a fiduciary to engage a processor "only under a valid contract".

Timing matters. Section 8 and Rules 3 and 5 to 16 of the DPDP Rules commence on 13 May 2027. Until then the IT Act's Section 43A and the 2011 rules on sensitive personal data still apply; Section 44(2) of the DPDP Act omits Section 43A once it commences. A five-year contract signed today will run under the new regime for most of its life, so draft for it now.

When the Rules apply, Rule 6(1) lists minimum safeguards, including encryption or masking, access control, logs and monitoring, backups, retaining logs and personal data for one year unless another law requires otherwise, and an "appropriate provision in the contract" between fiduciary and processor for reasonable security safeguards. Rule 8(3) has an illustration expecting the fiduciary to ensure its cloud processor also retains data and logs for at least a year.

Ask for:

• A list of sub-processors (hosting, backup, SMS, email) and prior notice of changes
• The hosting location stated in the contract; Section 16 lets the government restrict transfers to notified countries
• Erasure or return of data at the end, subject to legal retention periods (Section 8(7))
• Cooperation in breach response (next clause)

13. Security incidents, logs and audit

Two regulators set clocks here. CERT-In's April 2022 directions require covered entities to report specified cyber incidents "within 6 hours of noticing" them, keep ICT system logs "for a rolling period of 180 days" within Indian jurisdiction, and synchronise clocks with NIC or NPL time servers. When the DPDP Rules apply, Rule 7(2) asks the fiduciary to inform the Data Protection Board without delay and give a detailed report within 72 hours.

Your hospital cannot meet those clocks if the vendor tells you about an incident two days later. Ask for:

• Vendor notice to the hospital within a fixed number of hours of detecting an incident, well inside six
• Logs retained for at least 180 days in India and made available on request
• Annual third-party security testing with a summary report shared with the hospital

Our ransomware readiness guide covers the operational side.

14. Backups, recovery and restore tests

Write the recovery point objective (how much data you can lose) and recovery time objective (how long you can be down) into the contract, and require a documented restore test at least once a year with results shared.

Liability and termination

15. Liability, termination and disputes

Check three things. First, the liability cap: many vendor drafts cap liability at one year's fees and exclude data loss. Negotiate a separate, higher cap for data protection and confidentiality breaches. Second, termination rights: for cause (repeated SLA failure, insolvency, security breach) and for convenience with notice. Third, dispute resolution: venue, arbitration seat and governing law.

On liquidated damages, Indian contract law generally lets courts award reasonable compensation up to the sum named, rather than the full figure automatically, so tie credits and damages to a genuine estimate of loss. Ask your advocate how to structure this.

The clause checklist

• Data ownership stated plainly
• Export on demand, documented format, fixed days, no fee once a year
• 90-day read-only transition and migration support
• Escrow (on-premise) or weekly backup to hospital storage (cloud)
• Monthly uptime with automatic credits and a termination trigger
• Severity levels defined in hospital terms, 24x7 for Severity 1
• Annual price cap covering renewals
• Clear module scope and counting rules
• Payments tied to acceptance after live use
• Rate card for changes; defects vs enhancements defined
• Statutory and scheme updates included
• DPDP-ready processor terms, sub-processor list, hosting location
• Incident notice within hours; 180-day logs in India
• RPO, RTO and annual restore test
• Separate liability cap for data breaches; clear termination and dispute terms

A vendor that is confident in its product should be comfortable discussing most of this list. We wrote it from the buyer's side of the table: hold every vendor to it, Kōami included. For how to evaluate vendors before you get to the contract, see how to choose an HMS.

If you are reviewing a hospital software contract and want to see how we handle data export, SLAs and statutory updates, book a demo.