Product · Hospital Management Software

Hospital Management Software Built for How Indian Hospitals Actually Work

L.K. Monu Borkala, Founder, OneCity Technologies · Published 6 September 2026 · Updated on 6 September 2026

Most hospital management software sold in India was built for large metro hospitals with dedicated IT teams, reliable fibre connections, and budgets that treat a multi-lakh annual license as a routine line item. That leaves the 75-bed district hospital in Hubli, the 40-bed maternity hospital in Madurai, and the 120-bed multi-specialty in Raipur running either on paper, on disconnected departmental systems that do not talk to each other, or on software that costs more to maintain than it saves. OneCity is a hospital management system built for that second category of hospital: one database covering OPD, IPD, lab, pharmacy, billing, HR, inventory, and every Indian compliance mandate, running on the bandwidth and devices these hospitals actually have, starting free for up to 5 doctors.

What hospital management software actually needs to do in India

The phrase "hospital management software" covers a range wide enough to be meaningless without specifics. At minimum, an HMS in India must handle patient registration with ABHA linkage and UHID generation, appointment scheduling and queue management for outpatient departments, inpatient admission with bed allocation and ward-level tracking, laboratory information system (LIS) integration with sample tracking and result entry, pharmacy and drug dispensing with batch tracking and expiry alerts, billing with GST handling (including the healthcare exemption on room charges below a threshold and e-invoicing for taxable supplies), and insurance claim processing for both private TPA cashless and AB-PMJAY through NHCX.

That is the clinical and billing core. A hospital that buys software covering only these modules still needs separate systems for HR and payroll, inventory and procurement, accounting, quality and NABH audit documentation, biomedical waste tracking, dietary and nutrition, and regulatory compliance (FSSAI, AERB, PCPNDT, NDPS, Clinical Establishment Act or KPME). Running those in spreadsheets or standalone tools reintroduces exactly the data-duplication and reconciliation problem the HMS was supposed to eliminate. A hospital ERP covers all of these in one system, which is the difference between an HMS that digitises individual departments and an ERP that runs the hospital as one connected operation.

The compliance stack Indian hospitals face, and why it matters for software

Indian hospitals operate under more concurrent regulatory mandates than hospitals in most other countries, and each mandate has its own documentation, filing, and renewal cycle. ABDM (HFR registration, ABHA verification, health record exchange) is now effectively required for PMJAY claims and cashless insurance. NABH 6th edition requires structured electronic medical records, antimicrobial stewardship tracking, and cybersecurity controls. FSSAI requires per-premise canteen licensing with annual fee and FSCR filing under perpetual validity. AERB requires per-equipment radiation safety licensing. BMW Rules 2016 require colour-coded segregation manifests. PCPNDT requires Form F for every ultrasound with permanent retention. GST requires correct handling of exemptions, e-invoicing, and Bill of Supply for exempt services. DPDP Act 2023 requires consent management, data retention justification, and breach notification within 72 hours. And state-specific requirements like KPME in Karnataka or the Clinical Establishment Act add their own registration and renewal cycles.

Software that does not track these inside the same system where the clinical and billing data lives forces the compliance team to maintain a parallel universe of spreadsheets, folders, and calendar reminders. That parallel universe is where compliance lapses start: a renewal date missed because it lived in a spreadsheet nobody opened, a BMW manifest log that fell behind because the facilities team did not have access to the clinical system generating the waste classification data. Hospital management software that handles compliance alongside operations is not a premium feature; in the Indian regulatory environment, it is the baseline.

Why most hospital software does not fit a tier-2 or tier-3 hospital

Enterprise hospital software is designed for hospitals with three things a tier-2 or tier-3 facility typically does not have: a reliable high-bandwidth internet connection, a dedicated IT team to manage the system, and a budget sized for enterprise licensing. A 75-bed hospital in a district town runs on a mobile data connection that drops to 2G during peak hours. Its "IT department" is the accounts officer who also troubleshoots the printer. Its total annual software budget is less than what an enterprise vendor charges for implementation consulting alone.

The result is predictable: the hospital either stays on paper (and cannot participate in ABDM, struggles with NABH, and tracks compliance in registers), or buys a system that technically works but practically fails because it assumes infrastructure the hospital does not have. A ward nurse entering a discharge summary on a system that freezes every time the connection drops will go back to the paper register within a week, and the hospital has paid for software nobody uses. Building for tier-2 and tier-3 means building for 2 Mbps with intermittent outages, for Android tablets as the primary device, and for staff who will learn the system only if it is faster than the paper process it replaces.

There is also a training problem that infrastructure-heavy systems create. A system designed for a hospital with an IT department assumes that training is a scheduled event with a dedicated trainer, that users have email accounts for password resets, and that someone on staff can troubleshoot login issues at 2 AM when the night-shift nurse gets locked out. In a tier-2 hospital, training happens on the floor between patients, password resets go through a WhatsApp message to the vendor's support number, and the 2 AM lockout means the nurse writes the admission on paper and someone enters it the next morning. Software built for this environment has to account for these realities in its design, not treat them as edge cases to be solved by better IT support.

What to look for when evaluating hospital management software

The evaluation criteria that matter for an Indian hospital are not the same as the feature-comparison matrices that enterprise software reviews use. Module count is less important than module depth: a system that lists "pharmacy module" but cannot track batch numbers, handle drug interactions, or generate NDPS register entries for Schedule H1 drugs is not a pharmacy module, it is a dispensing screen. ABDM integration is not a checkbox: a system that can create an ABHA ID but cannot function as both HIP (Health Information Provider) and HIU (Health Information User) for bidirectional health record exchange is only half-integrated. NABH readiness is not a marketing claim: the test is whether the system produces the specific outputs an assessor asks for (coded discharge summaries, timestamped consents, quality indicator trend reports, incident logs with root-cause analysis) from data already being entered during care, without manual compilation.

Beyond features, three structural questions separate software that works from software that becomes shelfware. First: does the vendor publish its pricing, or does every conversation start with "let us understand your requirements"? Opaque pricing usually means the price adjusts to what the vendor thinks the hospital can pay, not to what the product costs to deliver. Second: what are the data export and exit terms? A hospital that cannot get a full export of its own data in open formats (CSV, HL7 FHIR, PDF) at any time is not a customer, it is a captive. Third: does the system work on the hospital's actual infrastructure, or does the hospital need to upgrade its internet, buy new hardware, and hire IT staff before the software becomes usable? The total cost of running the software includes every cost the software creates, not just the license fee.

The how to choose hospital management software guide covers this evaluation framework in full, and the 10-system comparison applies it to every major vendor including OneCity.

One final evaluation signal worth watching: how the vendor handles its own product page. A vendor that publishes pricing, names its limitations, and includes itself in competitive comparisons under the same criteria is telling you something about how it will behave as a long-term partner. A vendor that hides pricing behind a form, avoids naming competitors, and describes its product exclusively in superlatives is also telling you something. The product page you are reading now includes published pricing, honest comparisons where OneCity is scored alongside nine competitors, and a free tier with no time limit precisely because those are the signals a hospital should demand from any vendor it evaluates.

What OneCity does differently

OneCity is a single-database hospital ERP with 30 module groups covering every clinical, administrative, and compliance workflow an Indian hospital runs. It is built in Bengaluru for the operating environment of a 30 to 500 bed hospital in a tier-2 or tier-3 Indian city. Specifically: it works on 2 Mbps and continues operating during connectivity outages with automatic sync on reconnection. It runs on the Android tablets and desktops hospitals already own. It handles ABDM natively (ABHA verification at registration, HFR and HPR linkage, HIP and HIU roles for health record exchange, NHCX claim submission). It produces the structured documentation NABH 6th edition assessors expect (coded discharge summaries, timestamped consent records, quality indicator dashboards, incident reporting with trend analysis). It tracks every regulatory mandate listed above inside the same system, with renewal alerts, filing reminders, and inspection-ready reports.

Pricing starts free for up to 5 doctors, with no setup fee, no card requirement, and no time limit. Paid plans start at INR 999 per month and scale by bed count and active doctors, with every price published on the website rather than hidden behind a sales call. A hospital can run a full pilot on its own data before committing to anything, and the contract includes a data export clause guaranteeing full data portability in open formats at no additional charge on termination.

30 modules in one system

Rather than listing every module here, the modules page covers all 30 groups and 120 individual modules in detail. The key architectural point: every module reads and writes the same patient record, the same inventory, and the same financial ledger. A lab order placed during an OPD consultation updates the lab queue, the pharmacy stock (if consumables are involved), and the billing record in one transaction. A discharge summary pulls diagnosis, procedures, medications, and follow-up instructions from data already entered during the admission, not from a blank template the doctor fills out from memory. This is the practical difference between a system that digitises individual departments and one that runs them as a connected operation.

How hospitals are using OneCity now

The modules hospitals deploy first vary by their starting point. A hospital moving from paper typically starts with patient registration, OPD, billing, and pharmacy, because those four modules eliminate the most manual re-entry on day one. A hospital already running a basic HMS but lacking compliance and back-office coverage adds infection control (HAI surveillance), blood bank management, emergency and casualty, and the quality and NABH audit module. A hospital group with multiple locations uses the multi-location features for consolidated reporting, per-location GST handling, and a shared patient record across sites. The implementation timeline page covers how to sequence a phased rollout across departments without disrupting operations.

For hospitals also handling PMJAY and insurance claims, the PMJAY empanelment and claims module handles NHCX submission, package rate lookup, and de-empanelment risk tracking inside the same system where the clinical documentation lives. For hospital groups operating across multiple locations, the multi-location ERP features provide consolidated reporting, per-location GST registration handling, and a shared patient record so a patient seen at one branch does not start from scratch at another. And for hospitals in Karnataka specifically, the Bengaluru and Karnataka page covers how KPME registration, ABArK integration, and local compliance requirements fit into the system.

Implementation: what it actually takes to switch

Switching hospital software is the part nobody wants to talk about in a sales conversation, which is exactly why it belongs on a product page rather than buried in a post-sales onboarding document. A realistic implementation for a 50 to 150 bed hospital takes 4 to 8 weeks from contract to go-live, depending on whether the hospital is moving from paper (faster, because there is no data migration) or from an existing system (slower, because patient records, inventory, and financial data need to be imported and verified). OneCity handles data migration from any system that can produce a CSV export or a database dump. The migration runs in parallel while the old system stays live, and the hospital cuts over only after the team has verified the imported data and run a two-week parallel period where both systems operate simultaneously.

Training is on-floor, not classroom. Each department gets trained on its own modules during normal working hours, with a OneCity implementation specialist on site or on video for the first two weeks. The goal is not to train everyone on everything but to make each staff member faster at their own daily tasks within the first three days. If the software is slower than the paper process for any specific task, that is a product problem to be fixed, not a training problem to be managed.

Security, data protection, and the DPDP Act

Hospital data is among the most sensitive data any organisation holds: patient diagnoses, treatment histories, financial records, biometric identifiers (Aadhaar for ABHA linkage), and staff personal information. The DPDP Act 2023 made this personal, codifying consent requirements, purpose limitation, data retention justification, and a 72-hour breach notification obligation that did not exist before. A hospital running patient data through a system without role-based access controls, without audit trails showing who accessed which record and when, and without a documented data retention and deletion policy is not just operationally exposed, it is legally non-compliant under a law that carries real penalties.

OneCity handles this at the system level rather than leaving it to hospital policy alone. Role-based access means a billing clerk sees billing data but not clinical notes, and a nurse sees ward data but not HR records. Every access is logged with a timestamp, user ID, and action taken. Consent records are captured digitally with the specific purpose documented, not as a blanket checkbox. Data retention policies are configurable per record type, matching the statutory requirement (three years for general case sheets under NMC, five years for blood bank registers, permanent for PCPNDT Form F, working lifetime plus 30 years for AERB radiation dose records). And the system produces the breach notification documentation the DPDP Act requires, including the scope of affected data and the remediation steps taken, within the 72-hour window. For a deeper look at how this works, see the data security and CERT-In compliance guide and the role-based access control under DPDP guide.

How OneCity compares to other hospital software in India

The honest comparison of 10 hospital management systems scores each one on six dimensions: module depth, NABH readiness, ABDM integration, GST handling, offline capability, and pricing transparency. For head-to-head comparisons against specific vendors, see OneCity vs Practo, OneCity vs Bahmni, and OneCity vs HealthPlix. OneCity is included in every comparison and held to the same criteria. The how to choose hospital management software guide covers the evaluation framework hospitals should use regardless of which vendor they are considering.

This page is general product information. Regulatory requirements change; verify current compliance obligations on the relevant authority's portal before acting. For your hospital's specific situation, consult a qualified compliance professional.

Frequently Asked Questions

Sources and further reading

ABDM adoption figures are from the ABDM dashboard. NABH 6th edition standard details are from nabh.co. GST healthcare exemption provisions are per CBIC-GST. Regulatory requirements change; verify current obligations on the relevant authority's portal.