A 60-bed hospital in a district town signs for what the brochure calls an "EMR system". Six months in, the doctors are typing notes into it and nobody else is. Billing still runs on Tally. The pharmacy keeps its own stock register. The lab writes results on paper and someone carries them to the ward. The hospital bought software, and almost nothing about how the hospital runs has changed.
This happens often, and it usually is not because the software was bad. It is because the hospital needed one kind of system and bought another. EMR, EHR and HMS are three different products that get described with the same vocabulary, and the difference only becomes obvious after the money is spent.
Short answer: an EMR is one practice's clinical record of a patient. An EHR is the patient's record, built to move between providers with consent. A PHR is the patient's own copy, which the patient keeps and controls. An HMS runs the whole hospital — registration, beds, billing, pharmacy, lab and stock — and usually contains an EMR inside it. Most hospitals with beds are short of the HMS layer, not the EMR.
Here is what each one actually is — plus the PHR, which a hospital never buys but will keep hearing about — where they overlap, and how to tell which gap you are trying to fill.
What is an EMR? The clinical record inside one practice
An Electronic Medical Record is the digital version of the paper file a doctor keeps on a patient. Complaints, examination findings, diagnosis, prescription, follow-up notes. It belongs to one clinic or one hospital and it lives there.
The word that matters in EMR is medical. It is a clinical tool, built for the person treating the patient. A good one saves the doctor time — pulling up last visit's prescription instead of hunting through a file, flagging a drug the patient reacted to before, printing something legible for the pharmacy.
What an EMR does not do is run the rest of the building. It does not know how many beds are occupied, whether the patient has paid, what the pharmacy has in stock, or whether the lab has released a report. Those are not gaps in the product. They are simply outside what an EMR is for.
What is an EHR? The record that travels between providers
An Electronic Health Record is the same clinical information, but designed to move. The patient sees a physician in one city, gets a scan at a diagnostic centre, is admitted at a different hospital months later — an EHR is what lets that history follow them instead of being rebuilt from scratch at every desk.
The distinction is not about features. It is about scope and ownership. An EMR is the hospital's record of a patient. An EHR is the patient's record, which several providers can contribute to and, with permission, read.
That last clause is where most EHR conversations in India go wrong. Records moving between organisations only works if there is an agreed way to identify the patient, find the provider, and obtain consent. Without that shared plumbing, "EHR" is a software feature nobody can actually use — you can export a file, but there is nowhere standard to send it.
What is a PHR? The copy the patient keeps
A Personal Health Record is the patient's own record of their health, managed, shared and controlled by the patient rather than by any hospital. That is close to word for word how ABDM's own overview of PHRs defines it.
Under ABDM the PHR is usually an app, and the ABHA app is the government's own. With the patient's consent, a hospital links the records of a visit to the patient's ABHA address, and those records then appear in the patient's app beside records from labs, clinics and other hospitals. From there the patient decides who gets to see what.
The difference from an EHR is who holds the pen. Providers write into an EHR; a PHR sits with the patient. For a hospital, that means a PHR is not something to buy. It is the other end of the pipe, and the question to put to a vendor is not "do you have a PHR" but "when we create a record, can it reach the patient's app with their consent?"
What is an HMS? The operations layer for the whole hospital
A Hospital Management System is not primarily a clinical product. It is the system that runs the institution — the front desk, the wards, the money, the stock, the departments and the handoffs between them.
In practice, an HMS is what makes a patient one continuous event instead of eight disconnected ones. Registration creates a record the OPD desk can see. The doctor's prescription reaches the pharmacy without being carried there. Admission moves the patient into a bed the system knows is free. Lab orders come back attached to the right file. And at discharge, everything that was consumed is already on the bill.
Typically that means modules along these lines:
- OPD — registration, appointments, queue, consultation notes
- IPD — admission, bed allocation, nursing records, discharge summary
- Billing — consultation, procedures, packages, insurance and cash, refunds
- Pharmacy — stock, batch and expiry, indents from wards, sales
- Laboratory and radiology — order, sample tracking, result entry, report release
- Inventory and purchase — consumables, supplier orders, stock movement between stores
- Reports — collections, occupancy, department-wise revenue, statutory registers
Most HMS products include some form of clinical notes, which is exactly why the categories get muddled. An HMS usually contains an EMR. An EMR almost never contains an HMS.
What is the difference between EMR, EHR, PHR and HMS?
An EMR records what happened clinically inside one practice, an EHR lets that record travel between providers, a PHR is the patient's own copy of it, and an HMS runs the operations of the whole hospital. The three questions below show the difference quickly.
Who each one is built for
- EMR — the treating doctor, inside one practice
- EHR — the patient, across every provider they visit
- PHR — the patient again, but as its keeper: they hold it and decide who sees it
- HMS — the whole institution: front desk, wards, pharmacy, lab, accounts, management
What is still broken if you only have that one
- Only an EMR — notes are digital, but billing, pharmacy, lab and beds are still separate systems or registers, and the same patient gets entered several times
- Only an EHR capability — records can travel, but nothing inside your hospital is coordinated
- Only an HMS with weak clinical notes — operations run smoothly, but doctors keep writing on paper and clinical history stays thin
The single question that separates them
- EMR — what happened with this patient clinically?
- EHR — what has happened to this patient anywhere?
- PHR — what does the patient hold, and who have they chosen to show it to?
- HMS — what is happening in this hospital right now?
Where does ABDM fit, and where does it not?
The Ayushman Bharat Digital Mission is often described as though it were a product a hospital installs. It is not. A useful way to think about ABDM is as shared digital plumbing for India’s health ecosystem — an interoperability framework that lets health information move between participating systems. ABHA provides a unique digital health identifier for the individual, while registries of facilities and professionals, and consent-based exchange infrastructure, handle identity, discoverability and controlled sharing.
The records themselves do not move into a government database. A PIB explainer from April 2024 describes ABDM as a federated architecture: health records continue to be stored where they are created, by the provider that created them, and ABDM links those places together. A PIB release from August 2025 adds that health data is exchanged only after the patient's consent.
What ABDM supplies is the connective layer. What it does not supply is your hospital's software. It will not register your OPD patients, manage your beds, or count your pharmacy stock. Your HMS still has to do all of that — and additionally has to be able to speak to ABDM if you want records linking and consent to work.
That distinction is worth pressing a vendor on, because it is easy to blur. Simply having an ABHA field on the patient registration screen does not make a system ABDM-integrated. Participating in ABDM-enabled exchange means the software implements the relevant integrations and workflows — linking records to the identifier, handling consent requests, responding to information requests. A field you can type a number into is not the same thing, and “yes, we have ABHA” is not an answer to “are you integrated”.
So the honest framing is this: ABDM makes interoperable, consent-based health information exchange possible at the ecosystem level. It does not replace an HMS, and it does not become the hospital’s EHR. Being “ABDM ready” also tells you nothing about whether a system can run your hospital — those are two separate questions, worth asking separately.
Why do vendors blur the line between them?
Some of the confusion is genuine — the terms overlap and even people who work in health IT use them loosely. But commercial positioning adds to it. "EMR" and "EHR" sound clinical and modern. "HMS" sounds like billing software. A product with a consultation screen and a prescription printer is easier to sell as an EMR than to describe honestly as one module of something larger.
The pattern to watch for is a demo that spends most of its time in the doctor's screen. That screen is the easiest part to make impressive. The parts that decide whether the software survives contact with your hospital are the boring ones — what happens when an OPD patient gets admitted, whether the pharmacy sees the prescription without anyone retyping it, whether a discharge bill assembles itself or someone reconstructs it from four registers.
Ask to see those. A vendor selling a complete system will show you; a vendor selling one module will change the subject.
So which one do you actually need?
For a single-doctor clinic, an EMR with basic billing is often genuinely enough. There is no ward, no store, no lab — buying a full HMS means paying for and training on modules that will stay empty. What matters at that scale is a different checklist, and we have written separately about choosing clinic management software.
For anything with beds, a pharmacy and a lab, the constraint is almost never clinical notes. It is coordination. Patients getting re-registered, items dispensed but not billed, reports that exist but have not reached the ward. That is an HMS problem, and no EMR will solve it however good its prescription screen is.
EHR capability is best thought of as a property you want your system to have rather than a product you buy separately — the ability to link an ABHA number, share a record with consent, and receive history from elsewhere. Worth confirming a vendor supports it. Not worth choosing a system for, if that system cannot run your hospital.
The useful question is not which of the three is best. It is which layer your hospital is currently missing. If patient information is fine but nothing between departments connects, more clinical software will not help. If operations are running and doctors are still writing on paper, the gap is clinical. Being precise about that before the first demo is what separates hospitals that get value from their software from hospitals that quietly go back to their registers.
Where Zivyaa fits
The gap this article keeps returning to — departments that each work fine on their own and do not talk to each other — is the problem Zivyaa is built around. The bet is that most hospitals are not short of a better prescription screen. They are short of one record that registration, the ward, the pharmacy, the lab and the billing counter are all writing into, so that a patient is one event instead of six.
That includes the parts vendors prefer not to demo: what happens when an OPD patient is admitted, whether an indent from a ward moves stock without a phone call, whether a discharge bill assembles itself. And it has to survive the conditions it will actually run in — a district town where the connection drops mid-OPD, and a front desk with no appetite for a second data-entry screen.
It is honest to call that work in progress rather than a solved problem. Connecting departments that have run separately for years is slow, and anyone who tells you otherwise is selling. If that is the layer your hospital is missing, you can see how we are approaching it or book a walkthrough and ask the awkward questions from the list above.
