Hospital ERP AMC & Managed Support Plans

Most hospital software AMCs cover almost nothing

A typical AMC in this market means: if it breaks, someone will eventually come look at it. That's not a support plan, it's a promise with no timeline attached. A hospital running patient billing and pharmacy dispensing on a system needs to know, in writing, how fast a critical issue gets a response, and needs backups that have actually been tested, not just scheduled.

This gap matters more than most administrators budget for. An AMC line item usually gets negotiated once, at signing, and then forgotten until something breaks at 11 PM on a Saturday and the "24-hour response" clause turns out to mean 24 business hours, not 24 clock hours. The difference between those two readings of the same sentence is the entire point of this page.

What a real managed support plan includes

Every row in that table exists because a hospital somewhere learned it the hard way. Response-time SLAs exist because "we'll get to it" during a billing outage means patients wait at the counter with a discharge summary that can't be finalised. Security patching exists because unpatched systems are the entry point in the majority of hospital ransomware cases documented in our hospital ERP data security and CERT-In compliance guide. Backup verification exists because a backup job completing successfully and a backup actually being restorable are two different claims, and only one of them is usually tested.

What downtime actually costs, department by department

"Downtime" sounds abstract until it's broken into what actually stops working. None of the figures below are universal constants — get your own numbers from your own patient volume — but the structure of the cost is the same everywhere.

• Registration down: Every new OPD patient becomes a manual entry, and every existing patient's history is unavailable at the counter. Queue time roughly doubles, and repeat visits generate duplicate paper trails that have to be reconciled once the system is back.
• Billing down: Discharges stall. A patient medically cleared to leave stays in a bed because the bill can't be finalised, which is a bed-turnover cost as much as a billing cost.
• Pharmacy dispensing blocked: Inpatient medication administration either falls back to a manual register (which then has to be reconciled against stock later) or is delayed, which is a direct patient-safety issue, not just an operational one.
• Lab/LIS down: Result turnaround time extends, which delays every downstream clinical decision waiting on that result.

This is why the response-time SLA matters more than almost any other line in an AMC contract. A vendor with a fast patch cycle but a slow support response has optimised for the wrong thing.

There is also a cost that doesn't show up on any single day's ledger: patient trust. A hospital where the billing counter visibly breaks down in front of a waiting room, more than once, acquires a reputation locally that outlasts the actual outage by months. In tier-2/3 markets where word-of-mouth still drives a large share of patient choice, that reputational cost is real even though no accountant will ever put a number against it on a specific invoice.

Defining severity: critical, high and standard

The single most common AMC dispute is a hospital and a vendor disagreeing on which bucket an issue belongs in. Writing the definitions into the contract itself, with examples like the ones above, removes that argument before it starts.

It's worth noting that severity is about impact, not about how loudly a department complains. A single VIP patient's billing glitch and a hospital-wide registration outage can generate the same volume of phone calls to IT, but only one of them is actually critical by the definitions above. Holding to the written definition, rather than to whoever escalated most recently, is what keeps the SLA meaningful under pressure.

Auditing your current AMC contract: five questions to ask your existing vendor

1. Can you send me the written SLA document? If there isn't one, there is no SLA, regardless of what was said verbally at signing.
2. When was the last successful backup restore test, and what was the result? A date and a pass/fail outcome, not "we back up nightly."
3. What security patches were applied in the last two quarters? A vendor that can't produce a patch history is not patching on a schedule.
4. Are compliance updates included, or billed as separate change requests? GST rate changes and ABDM requirement updates happen on a regulatory timeline, not a convenient one — a vendor that treats each one as billable work creates an incentive to delay them.
5. What's the actual, not advertised, response time for a critical ticket raised at 2 AM? Ask for the last three critical tickets and their real resolution timestamps.

If your current vendor can't answer two or more of these cleanly, the AMC is a document, not a service. This is also worth revisiting alongside your broader hospital software pricing evaluation, since AMC terms are frequently where the real total cost of ownership hides, not in the headline licence fee.

Vendor responsibilities vs hospital responsibilities

Plan tiers

Hospitals rarely need to guess which tier fits. A single-site facility running standard OPD/IPD without a 24/7 ER is usually well served by Standard. A multi-specialty hospital that has completed a phased ERP implementation and data migration and is now running live claims through PMJAY or a private TPA typically needs Priority, since claim-processing downtime has its own financial consequence separate from patient care. Critical-Care tier exists for hospitals where a support gap is not an inconvenience but a patient-safety event.

Response-time commitments, spelled out by tier and severity

Vague language is where most AMC disputes start. Here is what each tier should commit to in writing, in actual minutes and hours, not adjectives.

Notice that even the Standard tier has a number attached to every row. "We will prioritise it" is not a commitment a hospital can hold a vendor to; "within 4 business hours" is.

Why support quietly gets deprioritised after go-live

At the point of sale, support is a selling point. Six months after go-live, it becomes a cost centre competing with new-feature development for the same engineering time. This is not unique to any one vendor — it is the natural incentive structure of software support anywhere, hospital or otherwise. The only real defence against it is a contract that ties specific, measurable response times to specific severities, reviewed at renewal, rather than a general goodwill relationship with whichever account manager answered the phone at signing.

This is also why a hospital's own implementation timeline matters for support planning, not just for go-live: the team that trained your staff and knows your specific configuration is the team you want answering critical tickets a year later, not a rotating support desk that has to re-learn your setup from documentation every time.

What a maintenance window actually looks like

A planned maintenance window is not downtime in the sense a critical incident is — it is scheduled, communicated in advance, and timed for low patient-impact hours, typically overnight or during a historically quiet period in the hospital's own patient flow data. What should be non-negotiable:

• At least 48 hours' advance notice for any maintenance that touches billing, registration, or pharmacy modules.
• A rollback plan agreed before the window opens, not improvised if the update goes wrong.
• A named person available during the window who can approve or halt the change in real time.
• Written confirmation after the window closes, including what changed and what to watch for over the following 48 hours.

Renewing your AMC: what to renegotiate every year

An AMC renewal is the one predictable moment each year to correct drift between what the contract says and what the hospital actually needs. Three things worth revisiting every renewal cycle, not just when something has gone wrong:

1. Severity definitions, if the hospital has added departments, claim types, or a 24/7 service line since the contract was signed.
2. Response-time numbers, if the hospital's own risk tolerance has changed — a hospital that has scaled from 40 to 90 beds usually can't tolerate the same critical-issue wait it accepted at 40.
3. What counts as included versus billable, particularly around compliance updates, since regulatory change (GST, ABDM, e-invoicing thresholds) doesn't pause for a contract's renewal date.

What good support looks like in the first year

The first twelve months after go-live are where a support contract is actually tested, not the sales conversation before it. A realistic pattern for a well-run AMC: a handful of standard tickets in month one as staff settle in, a spike around the first GST rate change or ABDM requirement update that the vendor absorbs without a separate invoice, one or two high-severity tickets tied to unfamiliar edge cases in real patient data, and, if the backup verification process is working, at least one uneventful test-restore drill logged and filed away. None of that requires the hospital to think about the AMC at all — which is the entire point. A support contract that requires constant hospital-side follow-up to get action is not delivering what it was sold as, regardless of what the SLA document says.

Budgeting for AMC costs without underestimating them

AMC pricing in this market is typically quoted as a percentage of the original licence or subscription value, or as a flat per-bed monthly fee layered on top of the core software cost. Neither number, by itself, tells a hospital whether the support behind it is real. The more useful budgeting question is not "what percentage is the AMC" but "what is the cost of one uncovered critical incident, multiplied by how many we're likely to have." A hospital that has never priced out a half-day billing outage tends to under-budget for support and over-budget for features it may never fully use. Anchoring the AMC line item to the downtime costs described earlier on this page, rather than to a generic percentage benchmark, produces a number a finance committee can actually defend.

Sources

CERT-In Directions under Section 70B(6), Information Technology Act, 2000 (cert-in.org.in). Central Board of Indirect Taxes and Customs, CGST Rules 2017 (cbic.gov.in).

Frequently asked questions

Related reading