eHospital@NIC is real, capable, ISO-certified government infrastructure used by over 1,000 public hospitals — and it's generally not available to private facilities at all. Here's what it actually is, and what that eligibility fact means if you administer a private tier-2/3 hospital.
NIC's own project page describes eHospital as a web-based, workflow-driven Health Information Management System, open-source, hosted on NIC's National Cloud (MeghRaj), with more than 1,000 health facilities across India currently using it, and it is ABDM-compliant. Its module set is genuinely comprehensive on paper: registration for OPD, casualty and emergency, IPD admission-discharge-transfer, billing, lab, radiology, laundry, dietary, operation theatre, store and pharmacy, plus a connected e-BloodBank application and ORS, a citizen-facing portal for online appointment booking, viewing lab reports and checking blood availability, accessible at ors.gov.in.
A newer version, NextGen eHospital, adds a microservices and container-based architecture, AI-enabled clinical decision support and tele-radiology, and 12 modules covering the same core hospital workflow. NextGen is currently live in 68 health facilities — a much smaller footprint than the original eHospital's 1,000-plus, which is worth noting plainly: the newer, more technically advanced version is still in an earlier stage of rollout than the system it's replacing.
Critically, NIC's own application listing states the software is "specifically meant for the hospitals in Government Sector", delivered as Software-as-a-Service to public hospitals across the country. This is public healthcare infrastructure, funded and operated for the government hospital system — not a product a private hospital administrator evaluates against a commercial quote.
The technical specification is genuinely thorough for a government system, and worth stating plainly rather than dismissing: the official eHospital FAQ page lists ISO/IEC 9126 certification, HL7 Development Framework compliance, Unicode-based Indian multilingual support, comprehensive role-based access control with audit logging of transactions, and PACS integration for imaging among its documented features. It also supports a touch-screen kiosk interface for patient-facing use and runs on a Linux platform. None of this reads like a minimum-viable government pilot — it reads like a mature, professionally engineered system that happens to be scoped for a different buyer than a private hospital administrator evaluating commercial vendors.
| Dimension | eHospital@NIC | OneCity |
|---|---|---|
| Who can use it | Government hospitals, provisioned by NIC/state health departments | Any hospital, private or public, that chooses to buy it |
| Cost to the hospital | Government-funded SaaS, not a market purchase | Paid tiers from ₹999, free tier to start |
| Vendor relationship | Government IT department / NIC support structure | Direct commercial vendor relationship with support included |
| Customisation for a specific private hospital's workflow | Built as generic government infrastructure, not tailored per-facility | Configured for tier-2/3 private hospital operations specifically |
| Module breadth on paper | Extensive — OPD, IPD, lab, radiology, OT, pharmacy, blood bank | Extensive — same core areas, plus NABH/PMJAY-specific documentation |
| NABH-structured discharge documentation | Not the documented design focus | Built in — structured to NABH format |
| Rollout scale of newest version | NextGen eHospital live in 68 facilities, smaller than the 1,000+ on the older version | Actively deployed and iterating with private tier-2/3 hospitals now |
| ABDM compliance | Yes | Yes |
Judged as public infrastructure, eHospital@NIC is a serious, credible achievement: open-source, ISO/IEC 9126 certified, HL7 Development Framework compliant, role-based access control with audit logging, and deployed at real scale across more than 1,000 government facilities — that is meaningfully larger production usage than most commercial Indian hospital software can claim. For a government hospital that qualifies for it, eHospital represents a genuinely capable, no-cost-to-the-facility system built specifically for the public sector's operating constraints, and the connected e-BloodBank and ORS citizen portal extend real value beyond the hospital walls to patients searching for appointments or blood availability nationally.
The ORS citizen portal specifically deserves a moment of its own, because it solves a problem few commercial products attempt at the same scale: a single national interface where a citizen anywhere in India can search for appointment availability, view lab reports, and check blood stock across participating government facilities, without needing to know which specific hospital system that facility runs internally. That's a genuinely different kind of value than any individual hospital's operational software provides on its own — it's a network effect built through central coordination, the public-sector equivalent of what a large private platform might otherwise try to achieve through market consolidation.
If you administer a government hospital and are evaluating whether to adopt or continue using eHospital, that's a genuinely different question than anything this comparison page can answer — it's a question for your state health department and NIC's own implementation team, not a private vendor comparison.
eHospital is also open-source, which might suggest the same "free but requires technical capacity" tradeoff we've described elsewhere in comparing OneCity against Bahmni — but the situation is meaningfully different in practice. Bahmni's open-source model puts deployment and maintenance responsibility on whoever adopts it, wherever they are. eHospital's open-source codebase is deployed, hosted and maintained centrally by NIC on its own government cloud infrastructure, with support delivered through a dedicated call centre and helpdesk to the government facilities using it. A public hospital using eHospital isn't standing up and maintaining the software itself the way a Bahmni adopter would — it's receiving a centrally-run service, open-source licensing aside. This distinction matters because it means the two "open source hospital systems" comparisons on this site aren't actually testing the same question, even though the license type sounds similar on paper.
eHospital's more than 1,000 facility deployments demonstrate something genuinely valuable: that a centrally-run, standardized HMIS can work at national scale across India's public hospital system, covering everything from casualty registration to blood bank management to radiology, with real Aadhaar-linked patient-facing services through ORS. That's a substantial public health achievement, and it's worth acknowledging directly rather than treating government software as inherently inferior to commercial alternatives, which is a lazy framing this comparison deliberately avoids.
What that scale doesn't demonstrate is anything about how the system performs against private-sector accreditation and claims documentation specifically, because that has never been its design target. NABH accreditation for a private facility, PMJAY empanelment on commercial terms, and GST-compliant private billing workflows are simply not the problems a government-hospital-focused HMIS was built to solve, in the same way a car built for city commuting isn't a worse car for failing to tow a trailer — it was never meant to.
eHospital's support runs through NIC's dedicated call centre and helpdesk structure, serving government facilities through official government channels — a model built around consistency across thousands of facilities rather than individual account responsiveness. A commercial vendor relationship works differently: a private hospital that's paying for OneCity has a direct commercial relationship with an account team whose job is specifically to respond to that hospital's needs, escalate issues quickly, and prioritize feature requests based on paying customer feedback. Neither model is wrong — they're built for different accountability structures. A government helpdesk answers to a government reporting chain; a commercial vendor answers to the customer paying the invoice. If your hospital genuinely needs the second kind of relationship, that's not something eHospital's structure, however well-run, is designed to provide.
Escalation paths make this concrete. If a critical bug affects billing at 11 PM on a Saturday, a commercial vendor's support obligation is contractual and specific — typically a defined response-time commitment in the service agreement. A government helpdesk's obligation runs through its own internal ticketing and prioritization process across every facility it serves nationally, which is a reasonable and necessary structure for managing thousands of facilities fairly, but is not the same thing as a single hospital having a dedicated point of commercial accountability for its own uptime.
Not "does it feel like a government hospital" — get a direct written answer from your state health department or NIC contact about eHospital eligibility for your specific facility.
Identify specifically which private-sector workflows — NABH documentation, private billing, PMJAY empanelment on commercial terms — aren't covered by your current eHospital deployment, rather than assuming a wholesale replacement is the only option.
Spend your evaluation time comparing commercial products against each other — see our comparisons against Practo, Bahmni, and HealthPlix for that evaluation.
Three real situations bring a private tier-2/3 hospital administrator to this comparison. First, simple search confusion — "eHospital" and "hospital software" turn up in the same searches, and it's worth knowing upfront that eHospital isn't an option available to purchase. Second, a public-private partnership context, where a facility operates under some government affiliation and needs to understand whether eHospital's provisioning applies to their specific arrangement — that's a question for the relevant health department, not something a feature comparison resolves. Third, and most common: a hospital administrator has heard that "the government has free software" and wants to know if that's a real alternative to paying for a commercial product. The honest answer is no, not for a private facility — eHospital is provisioned to public hospitals through government channels, and a private hospital's actual choice is between commercial products, not between a commercial product and free government software.
There's a fourth situation worth naming, since it's a genuinely common path for tier-2/3 facilities in India: a hospital that began as, or is affiliated with, a government or trust-run institution, and later transitions toward operating more like a private facility — accepting private patients, pursuing NABH accreditation aimed at a private-sector standard, or seeking PMJAY empanelment on commercial terms. In that transition, a facility may find that eHospital's government-oriented design doesn't map cleanly onto the private-sector documentation and billing workflows the hospital now actually needs, even if the facility technically retains eHospital access. That's a legitimate, concrete moment to actually evaluate a commercial product specifically built for the operational reality the hospital has genuinely grown into, rather than the one it merely started from years earlier.
The reverse transition happens too, and is worth naming for completeness: a private facility entering a public-private partnership arrangement for the first time, taking on some government-provisioned patients or infrastructure alongside its existing private operations. That facility faces the opposite integration question — whether its existing commercial software can accommodate whatever reporting or data-sharing obligations the partnership introduces, on top of what it already runs for its private-sector patient base. Either direction, the practical lesson is the same: a facility's software needs should be reassessed at the moment its operational status actually changes, not assumed to remain fixed and unchanging indefinitely from whichever system the facility happened to start with years earlier.
This transition is worth planning deliberately rather than letting it happen by default. A trust hospital that gradually accepts more private patients without ever formally re-evaluating its software stack often ends up running two parallel record-keeping habits — the government system for what it was originally provisioned to handle, and an assortment of spreadsheets or a second tool for the private-sector documentation nobody configured the original system to produce. That's a worse outcome than either a clean government deployment or a clean commercial one; it's the fragmentation this whole comparison is trying to help a hospital administrator avoid.
A related, fifth situation worth a brief mention: multi-location groups that operate a mix of facility types — some fully private, some with a government or trust affiliation — sometimes end up running eHospital at one site and a commercial product at another simply because eligibility differs facility by facility, not by strategic choice. If that's your situation, our note on multi-location hospital ERP for chains and groups is worth reading specifically for how to think about data consistency and reporting across a genuinely mixed fleet, rather than assuming every facility in the group can or should run the same system.
OneCity is a direct commercial product available to any hospital that chooses to buy it, with IPD and bed management, ICU charting, OT scheduling, pharmacy and blood bank modules configured specifically for private tier-2/3 hospital operations, with NABH-structured documentation and PMJAY claims-ready data built in. Because it's a commercial relationship rather than government-provisioned infrastructure, a private hospital gets a direct support relationship, a product roadmap responsive to paying customers, and no dependency on a government rollout timeline or eligibility determination outside its control.
This also means feature velocity works differently between the two. A government system's module set, however comprehensive on paper, moves at the pace of centralized procurement, budget cycles and phased national rollout — which is precisely why NextGen eHospital, the more technically advanced version, is live in only 68 facilities years after the original eHospital reached over 1,000. A commercial product's roadmap moves at the pace of customer demand and competitive pressure, for better or worse. Neither pace is inherently superior, but a private hospital evaluating how quickly a new regulatory requirement — a DPDP Rules update, a new PMJAY package code, a Labour Code change — gets reflected in the software it depends on should understand which pace it's actually signing up for.
The scale comparison is worth being honest about too: eHospital's 1,000-plus facility footprint is real and larger than most individual commercial hospital software vendors can claim, precisely because it's centrally mandated government infrastructure rather than something each facility chose to adopt independently. That scale reflects a different kind of achievement — successful centralized public-sector rollout — than a commercial product's growth, which reflects individual hospitals independently choosing to pay for and adopt it. Neither kind of scale is more legitimate than the other; they're just answering different questions about adoption.
If you're a government or government-affiliated facility, ask your state health department or NIC directly whether eHospital provisioning applies to you — this is a genuine administrative question, not something a vendor comparison settles.
Your real evaluation is between commercial products — see our wider guide to choosing a hospital ERP for tier-2 and tier-3 hospitals.
Before assuming either eHospital or a commercial product applies to a public-private partnership facility, get a written determination rather than assuming based on general information.
Generally no. NIC's own application listing describes eHospital as software specifically meant for hospitals in the Government Sector, delivered as Software-as-a-Service to public health facilities. It is not sold or provisioned to private hospitals as a commercial product.
A web-based, workflow-driven Health Information Management System built by India's National Informatics Centre, open-source, hosted on NIC's National Cloud (MeghRaj), currently used by more than 1,000 government health facilities across India, and compliant with the Ayushman Bharat Digital Mission.
NextGen eHospital is a newer version built on a microservices and container-based architecture with AI-enabled clinical decision support and tele-radiology, covering 12 modules. It is currently live in 68 health facilities, a considerably smaller footprint than the original eHospital's 1,000-plus facilities, indicating it is earlier in its rollout.
It is government-funded infrastructure provided to public hospitals rather than a commercial product with a market price. There is no purchase path for a private hospital comparable to buying a commercial hospital ERP.
This is not documented as a specific design focus. eHospital's module set is built around general government hospital workflows — OPD, IPD, lab, radiology, OT, pharmacy, blood bank — rather than private-sector NABH accreditation documentation specifically.
Because search confusion is real — the name appears alongside commercial hospital software searches, and private hospital administrators sometimes ask whether "free government software" is a genuine alternative to a paid product. The honest answer is that it generally isn't an option for a private facility, and that eligibility question is more important than any feature comparison.
Running a private hospital and want a direct commercial vendor relationship, not a government provisioning question?
Book a demo