The Complete Hospital Management System Module List, and Which Ones You Actually Need

Every HMS proposal contains a module list. It is usually the longest page in the document, it usually has thirty or forty entries, and it is usually the least useful page for making a decision, because two vendors can list the same module name and mean wildly different things by it.

This is the module list explained: what each one is, what it must contain to be real, and which ones a hospital of your size actually needs on day one. Read it as a checklist to hold up against any proposal.

What are the core modules every hospital management system must have?

Six. Without all six you do not have an HMS, you have a department tool.

• Patient registration and master index. One identity per patient, with duplicate detection, ABHA creation and linkage, and demographic capture. Everything else hangs off this. A weak patient master produces a decade of merged-record problems.
• OPD management. Appointments, queue and token, consultation recording, prescriptions, and follow-up scheduling.
• IPD management. Admission, bed allocation, transfer, daily care recording, discharge summary, and the ADT event stream that the rest of the hospital depends on.
• Billing and revenue. Tariffs, package and open billing, advances, interim bills, insurance and cash splits, credit notes, and the final bill.
• Pharmacy. Dispensing against orders, batch and expiry, stock, and the charge reaching the bill.
• Reports and MIS. Census, revenue, department productivity, and the statutory returns.

Which clinical modules matter, and what makes them real?

The clinical layer is where proposals are vaguest, because "EMR" is a word rather than a specification.

Electronic medical record. The test is whether data is structured. Coded diagnoses, structured orders, results as values rather than as scanned images, and templates by speciality. A rich-text editor with a spell-checker is not an EMR; it is a word processor inside a hospital system, and nothing it holds can be reported on.

Nursing and clinical charting. Vitals, intake and output, medication administration records, care plans, and assessment forms. This is the module most often bought and least often used, because it is the one that adds work at the bedside unless it is genuinely fast.

Order management. Orders placed once, reaching the lab, radiology and pharmacy without re-entry, with status visible to the person who ordered.

Laboratory information system. Sample collection with barcoding, analyser interfacing so results arrive electronically rather than typed, validation rules, and turnaround time measurement. Analyser interfacing is frequently a separate charge per instrument. Ask.

Radiology and imaging. Order to modality worklist, reporting, and the images accessible from the patient record. Whether PACS is included or integrated is a question that must be answered explicitly.

Operating theatre. Scheduling with conflict detection across surgeon, theatre and equipment, pre-operative checklist, intra-operative notes, implant and consumable recording, and the link to billing.

Emergency. Triage category on arrival, rapid registration for unidentified patients, and the handover to inpatient care.

The modules a hospital regrets buying are rarely the ones it did not need. They are the ones it needed and bought in a version too shallow to use.

Which modules are driven by Indian regulation?

Five, and each is a licensing or accreditation obligation rather than a convenience.

• Blood bank. Donor registration, screening, component preparation, crossmatch, issue and the statutory registers. A blood bank is a separately licensed establishment; the software has to reflect that.
• NDPS register. Narcotic and psychotropic stock and dispensing, with the register generated from live transactions.
• Biomedical waste. Category-wise generation, handover records, and the annual return.
• Birth and death registration. Statutory records and the certificates.
• Insurance, TPA and PM-JAY. Pre-authorisation, claim assembly with documents, rejection handling and resubmission. If schemes are a meaningful share of revenue, this is not a module, it is the revenue cycle.

Which administrative modules are worth having in the same system?

Four, and the argument for each is that they share data with clinical operations rather than sitting beside them.

Inventory and procurement. Indents, purchase orders, goods receipt with batch capture, multi-store stock. Shares batch and expiry with pharmacy and consumption with theatre.

Human resources and payroll. Rostering, attendance, statutory payroll, credential expiry. Shares clinical activity with consultant payouts.

Accounts and finance. At minimum, a clean export to the accounting system with a defined chart of accounts mapping. Full financial accounting inside the HMS is less common and rarely necessary.

Biomedical equipment maintenance. Asset register, preventive maintenance, breakdown, calibration. Shares hospital structure and spares inventory.

What does a hospital of my size actually need on day one?

Fewer modules than the proposal contains, implemented properly, rather than everything implemented thinly.

A clinic or nursing home under thirty beds needs registration, OPD, IPD basics, billing, pharmacy and reports. Add lab if the lab is in-house. Everything else can wait, and buying it early means paying maintenance on unused software.

A hospital between thirty and a hundred beds adds a real lab module with analyser interfacing, EMR with structured orders, theatre scheduling, inventory, and insurance handling if schemes matter. This is the size at which the patient master and billing depth start to hurt if they were chosen carelessly.

Between one hundred and three hundred beds, nursing charting, radiology integration, blood bank if licensed, HR and rostering, biomedical maintenance, and proper MIS become necessary rather than optional. Multi-store inventory is no longer a convenience.

Above three hundred beds, or across multiple branches, the questions change shape entirely: consolidated identity and reporting across sites, per-site configuration, integration architecture, and performance under concurrency matter more than any individual module's feature depth.

How should the module list be used in a negotiation?

As a scope definition, not as a score.

Three habits protect a hospital here. First, ask for each module to be priced individually even if you buy a bundle, so you know what you are paying maintenance on. Second, ask which modules are included in the implementation scope and which are licensed but not configured, because those are different things and the gap is where go-live delays live. Third, ask what is on the roadmap rather than shipped, and get the distinction in writing.

A bundle discount on modules you will not use for three years is not a discount. It is three years of maintenance on shelfware.

What is the module list missing?

The things that decide whether the system works, none of which appear as a module.

• The patient master's duplicate handling
• Print speed at the billing counter
• What happens during a network outage
• Concurrency at peak OPD
• Whether the API is documented and open
• What the data export looks like
• Who implements it, and how many hospitals they have done

Kōami is built as one connected system across hospital management, workforce, inventory, imaging, fertility and biomedical equipment, which means most of the list above shares one patient identity and one data model rather than being stitched together. That design decision matters more, in practice, than the length of anybody's module list, including ours.