Hospital HMIS
Hospital management software
for how hospitals actually run.
Polynexus HMIS runs the clinical, diagnostic, pharmacy, billing and administrative sides of a hospital on one record — and puts a patient CRM on the same database, so front-office work and clinical work stop living in different systems.
In short
Polynexus HMIS is a cloud-based hospital management information system that runs a hospital’s clinical, diagnostic, pharmacy, billing and administrative records in one database, with a patient-facing CRM built into the same system.
It covers OPD and IPD, emergency, ICU, operation theatre, nursing, laboratory, radiology, blood bank, pharmacy, billing and insurance, inventory, finance and HR, plus enquiry handling, telephony, referrals and patient feedback. It is built and operated by Polynexus, a software company in Nagpur, Maharashtra, and is sold to hospitals in India.
At a glance
Who it is for
Built for multi-department hospitals, not single clinics
The system assumes departments that hand work to each other — and that the handover is where most hospital software falls apart.
- Multi-speciality hospitals running OPD alongside inpatient wards, ICU, operation theatre and an emergency department, where a patient moves between all of them on one visit.
- Hospitals with in-house diagnostics — a laboratory, a radiology department or both — that want orders raised from the consultation rather than re-entered at the collection counter.
- Hospital groups where staff work across more than one unit and management wants comparable numbers from each, without each unit keeping its own spreadsheet.
- Hospitals with a front office that markets — enquiry desks, call centres, referring-doctor relationships, health camps and corporate tie-ups whose results currently never connect to what the hospital actually billed.
Problems it solves
The gaps that cost hospitals money quietly
Most hospital software problems are not missing features. They are seams — places where one system stops and a person with a register takes over. These are the seams this product is designed to close:
- Enquiries that never become appointments. Calls and web enquiries sit in a diary nobody reviews. Here they are a tracked pipeline with stages, reassignment and callback tasks, and the enquiry funnel report shows where they die.
- Billing assembled from memory. When investigations, pharmacy and bed charges live in separate books, the final bill is a reconstruction. Bills built from the actual clinical record stop leaking revenue.
- Occupancy nobody can quote. Bed and ICU occupancy come from real bed allocations rather than a whiteboard, so the number is current rather than remembered.
- Results released before they are checked. Lab results and radiology reports carry an explicit verification step, so a provisional value cannot reach a patient as a final one.
- Referrals that cannot be credited. Referring doctors are tracked as records with a league table, so the hospital knows who actually sends patients instead of guessing.
- Attendance re-keyed into payroll. Staff attendance, shifts and leave sit in the same system as employee records, so payroll input is not a monthly re-typing exercise.
Modules
What is in the system
Every module below corresponds to live functionality in the platform. Nothing here is roadmap.
Patient records & registration
Patient master with lookup, a consolidated patient timeline, uploaded documents and prescriptions. Paperless registration lets a patient submit their own details before arriving at the counter.
Records: Patient, Document, Prescription, Paperless Registration.
Appointments & OPD
Slot templates generate bookable slots per doctor. Appointments move through check-in, start-consult, complete, reschedule, cancel and no-show, with a waitlist for full clinics and a live doctor queue.
Records: Appointment, Doctor, Slot, Slot Template, Waitlist.
Clinical documentation
Each OPD encounter carries vitals, clinical notes, diagnoses and investigation orders. Notes and diagnoses are finalised explicitly, so a signed record is distinguishable from a draft.
Records: Encounter, VitalsReading, ClinicalNote, Diagnosis, InvestigationOrder.
IPD, wards & beds
Ward, room and bed masters feed admission and bed allocation. Ward transfers require approval, doctors file progress notes, and discharge produces a finalised discharge summary against the admission.
Records: Ward, Room, Bed, Admission, BedAllocation, WardTransfer, DischargeSummary.
Nursing
Nursing notes, medication administration records and intake/output charting recorded against the admitted patient rather than kept on paper at the nursing station.
Records: NursingNote, MedicationAdministration, IntakeOutput.
Emergency & ICU
Emergency department visits with triage, and a direct admit-to-IPD action when a case is escalated. ICU carries its own admission record, daily progress notes and ventilator logs.
Records: Triage, EDVisit, ICUAdmission, ICUDailyProgressNote, VentilatorLog.
Operation theatre
Surgery requests, OT scheduling, pre-operative checklists, anaesthesia records, operative notes, and consumable and implant usage captured against the procedure.
Records: SurgeryRequest, OTSchedule, PreOpChecklist, AnaesthesiaRecord, OperativeNote, ConsumableUsage, ImplantUsage.
Laboratory & radiology
Test and package masters, orders raised from a consultation, sample collection tracking, and results and reports that carry an explicit verification step before release.
Records: LabTest, LabTestPackage, LabOrder, SampleCollection, LabResult, RadiologyProcedure, RadiologyOrder, RadiologyReport.
Blood bank
Donor records, blood unit inventory, cross-match requests and transfusion records kept in the same system as the admission they belong to.
Records: Donor, BloodUnit, CrossMatchRequest, Transfusion.
Pharmacy
Medicine master with batch and supplier tracking, dispensing against prescriptions, stock adjustments, and a low-stock report that flags what needs reordering.
Records: Medicine, MedicineBatch, Supplier, DispenseRecord, StockAdjustment.
Billing, TPA & finance
Bills, payments and receivables, insurance claims with TPA companies and pre-authorisation requests, plus an expense ledger with an approval step for outgoing spend.
Records: Bill, Payment, Receivable, InsuranceClaim, TPACompany, PreAuthRequest, Expense, Ledger.
Inventory & purchasing
Item categories and items, stock levels by location, purchase orders and stock transactions — the non-pharmacy side of hospital consumables and assets.
Records: ItemCategory, Item, StockLevel, PurchaseOrder, StockTransaction.
HR & rostering
Employee records linked to system users, staff attendance, shift assignment, and leave requests with approve and reject actions.
Records: Employee, Attendance, Shift, LeaveRequest.
Analytics & daily MIS
Operational reports covering OPD volume, bed and ICU occupancy, OT utilisation, lab turnaround time, doctor revenue, revenue by source, pharmacy low stock, enquiry funnel, call performance and no-show effectiveness, with a daily MIS log and preview.
Fifteen report endpoints, refreshed from live operational data.
Workflow
One record, from first call to final bill
A visit starts as an enquiry or a booking against a real doctor slot, moves through registration, check-in and the consultation itself, and picks up investigation orders and a prescription along the way. Diagnostics and pharmacy work off those orders directly, and the bill at the end is assembled from what actually happened rather than reconstructed afterwards. Every step is a record in the same database, not a handover between separate systems.
See the full OPD visit walked through step by step, or read how the inpatient path works on admission, bed allocation and discharge.
Deployment
Cloud by default, dedicated where it is required
Polynexus HMIS is delivered as a cloud service. Polynexus builds, hosts and operates the infrastructure itself rather than outsourcing data handling to a third party, and the hosting region can be pinned to India on request. Hospitals that need their own instance — for procurement policy, for a group-wide deployment, or to keep data on named infrastructure — can have a dedicated or self-hosted deployment.
The platform is multi-tenant, with data isolated per hospital. A staff account can be scoped to a single unit, and users who work across a group can switch between hospitals without a second login.
Choosing between the two models is a real decision, not a formality. Our guide to cloud versus on-premise hospital software sets out what each one actually commits you to.
Security & privacy
Patient data handled as patient data
Hospital records are among the most sensitive categories the DPDP Act recognises. The platform is built accordingly.
Encrypted patient identifiers
Patient contact details are stored encrypted at the field level and decrypted by the API layer for authorised callers, so the raw database does not hold readable patient phone numbers and names.
Role-based access with audit logging
Roles define what each user may see and do, and an audit log records administrative actions. Staff accounts can be scoped to a single hospital within a multi-hospital group.
Encrypted payload sessions
The API supports an ECDH key-exchange step that establishes an encrypted payload session, on top of transport encryption, for clients that require it.
DPDP Act 2023 data rights
Data rights requests for access, rectification and erasure run as tracked workflows with verification, completion and rejection steps, alongside grievance tickets and nominee records.
Polynexus does not hold a HIPAA, ISO 27001 or NABH certification, and nothing on this site should be read as claiming one. What is described above is how the software is built.
Integrations
What it connects to
ABDM / ABHA and NHCX
Polynexus is developing Polynexus HMIS’s integration with the ABDM ecosystem. The backend has API endpoints for initiating an ABHA link, verifying the OTP, checking link status, raising and checking consent requests, fetching health records and handling NHCX transactions, with the identifier used to initiate a link forwarded to the ABDM gateway rather than stored — but that describes what has been built, not a finished, customer-ready feature.
Status: in development. Polynexus is not ABDM-certified, ABDM-approved or empanelled by the National Health Authority.
Existing HIS systems
Where a hospital already runs another HIS, visit and billing records can be brought across through dedicated integration endpoints, with an integration health check to confirm the link is live.
Records: HISVisit, HISBillingRecord, IntegrationHealth.
FHIR export
Records can be exported in FHIR resource form, which is the format ABDM and most interoperability requirements are built around.
Telephony and lead sources
Inbound telephony webhooks and lead webhooks let the call system and external campaign sources push events straight into the CRM pipeline.
ABDM is the question we are asked most often, and the honest answer has more detail in it than a yes or a no. Read where our ABDM and ABHA work currently stands.
Implementation
How a hospital gets onto it
Nobody switches a running hospital over in a weekend. The sequence below is the one that works.
- 01
Scoping against your departments
We map your actual departments, handovers and billing rules before anything is configured. Hospitals differ more than vendors admit, and this is where a bad implementation is decided.
- 02
Masters and configuration
Wards, rooms and beds; doctors and slot templates; services and tariffs; test and medicine masters; roles and permissions. Getting masters right early removes most later rework.
- 03
Data migration
Existing patient records, outstanding bills and stock positions are brought across — from an existing HIS through the integration endpoints where one is in place, or from exports where it is not.
- 04
Department-by-department rollout
Usually front office and OPD first, then diagnostics and pharmacy, then IPD and theatre. Each department goes live once its own staff can work in it, not on a fixed calendar date.
- 05
Parallel running
For a defined period the old process runs alongside the new one on billing and stock, so discrepancies surface while there is still a fallback.
- 06
Training and go-live
Training is by role — a ward nurse, a billing clerk and a consultant each need a different half-hour. Go-live happens after the people who will use it daily have done so on real data.
Our hospital software implementation guide covers this in detail, including the checklist to run before you commit to a switch date.
Seeing it
A walkthrough on a live system
We do not publish screenshots of patient screens. We show the system running, against workflows that match your hospital.
A demo is a screen share against a working instance: we register a patient, book them into a doctor's slot, run the consultation, raise a lab order, dispense from pharmacy, admit and discharge, and produce the bill and the day's MIS. You see the real product doing your real sequence, and you can ask what happens when it goes wrong.
FAQ
Hospital management software — common questions
- What is the difference between an HMIS and an EMR?
- An EMR is the clinical record for a patient — notes, diagnoses, results, prescriptions. An HMIS is the whole operating system of the hospital: it contains the clinical record, and also registration, appointments, wards and beds, pharmacy, laboratory, inventory, billing, HR and reporting. Polynexus HMIS includes clinical documentation as one part of a larger system.
- Is Polynexus HMIS ABDM-integrated or ABDM-certified?
- Polynexus is developing Polynexus HMIS’s integration with the ABDM ecosystem and is not ABDM-certified, ABDM-approved or empanelled by the National Health Authority. The platform’s backend has API endpoints for the technical building blocks — ABHA linking with OTP verification, consent requests, health record fetch, NHCX transactions and FHIR export — but that is a description of what has been built, not a claim that ABDM workflows are a finished, supported feature today. We are happy to walk a hospital through exactly where that work currently stands before any commitment is made.
- Does it work for a single hospital or a group?
- Both. The platform is multi-tenant, and a user account can be scoped to one hospital or switched between hospitals in a group, with data isolated per tenant.
- Does the system include a CRM, or is that a separate product?
- It is the same product. Enquiries, telephony, appointment conversion, communications, referring-doctor tracking, campaigns and NPS feedback run on the same database as the clinical and billing modules, which is why reports like enquiry funnel and no-show effectiveness can be produced at all.
- Can it run alongside an HIS we already have?
- Yes. There are dedicated integration endpoints for bringing visit and billing records across from an existing HIS, plus an integration health check. Hospitals commonly start with the CRM and analytics layer over an existing system before migrating clinical modules.
- Where is the data hosted?
- On cloud infrastructure that Polynexus builds and operates itself, which can be pinned to an Indian region on request. Dedicated or self-hosted instances are available for enterprise deployments.
- What does Polynexus HMIS cost?
- Pricing depends on the modules deployed, the size of the hospital and whether the deployment is shared-cloud or dedicated, so we quote after a scoping call rather than publishing a list price. Ask for a demo and we will size it against your actual departments.
See it against your hospital's workflow
Tell us your departments and how patients move between them. We will run the demo on that sequence rather than a generic script.