Skip to main content

Reference

Healthcare IT glossary for hospitals

79 terms a hospital administrator, clinician, or healthcare IT buyer is likely to meet — standards, privacy and accreditation frameworks, clinical records, department systems, and revenue cycle vocabulary. Written as a reference, not a pitch.

Standards & interoperability

The data formats, code systems, and messaging standards that let hospital systems exchange records with each other, with labs and imaging equipment, and with national health networks.

DICOM (Digital Imaging and Communications in Medicine)

DICOM is the international standard that defines how medical images and their associated patient and study metadata are formatted, stored, and transmitted between imaging equipment and software.

A DICOM file is not just a picture. Each image carries an embedded header holding patient identifiers, accession number, study and series descriptions, modality, acquisition parameters, and the referring clinician. This is why a CT study pulled from an archive still knows which patient and which order it belongs to, and why a mismatch between the header and the hospital's patient record causes studies to land against the wrong chart.

In practice a hospital encounters DICOM at three points: the modality itself (CT, MRI, ultrasound, digital X-ray), the archive that stores studies, and the viewer radiologists read on. Vendors advertise DICOM conformance statements — the document that lists exactly which DICOM services and transfer syntaxes a device supports. When an integration between a modality and an archive fails, the conformance statements of both ends are the first thing to compare.

FHIR R4 (Fast Healthcare Interoperability Resources, Release 4)

FHIR is an HL7 interoperability standard that models health data as discrete resources — Patient, Encounter, Observation, MedicationRequest — exchanged over ordinary web APIs, with Release 4 being the version most widely implemented and the basis of India's ABDM record formats.

FHIR's practical advantage over older messaging standards is that it uses conventions ordinary web developers already know: REST endpoints, JSON or XML payloads, and resources addressable by URL. A request for a patient's lab results is an HTTP GET against an Observation endpoint rather than a positional pipe-delimited message that needs a specialist interface engine to parse.

R4 matters specifically because it was the first release to carry normative status for its core resources, which gave vendors a stable target to build against. ABDM defines its health record types — prescriptions, diagnostic reports, discharge summaries, OP and IP consultation records — as FHIR bundles profiled for India, so a hospital system that intends to exchange records over the national network is effectively required to produce and consume valid FHIR.

HIE (Health Information Exchange)

Health information exchange is the movement of patient health records between separate healthcare organisations, and also refers to the network or infrastructure that makes such movement possible.

The term is used two ways, which causes confusion in vendor conversations. As a verb it describes the act — a diagnostic centre sending a report to the referring hospital. As a noun it describes the intermediary that routes those records, holds the participant directory, and enforces consent. ABDM's gateway plays the noun role for India, brokering requests between health information providers and users without itself becoming a central store of patient records.

Exchange is harder than it sounds because identity, not transport, is the bottleneck. Two hospitals can both speak FHIR fluently and still fail to exchange anything useful if they cannot agree that their respective records describe the same person. Federated identifiers such as ABHA exist largely to solve that problem.

HL7 v2 (Health Level Seven, Version 2)

HL7 v2 is a long-established healthcare messaging standard that transmits events such as admissions, orders, and results as pipe-delimited text messages, and remains the most common way hospital systems talk to laboratory analysers and legacy departmental software.

An HL7 v2 message is a set of segments, each a line beginning with a three-letter code. ADT messages carry admit, discharge, and transfer events; ORM carries orders; ORU carries observation results. A lab analyser reporting a haemoglobin value back to the laboratory system is almost certainly doing it over HL7 v2, and will keep doing so for years — the installed base is enormous and the equipment lifecycle is long.

The standard's weakness is that it is heavily optional. Two conformant v2 implementations frequently cannot talk without a mapping layer, because each has made different choices about which optional fields carry which local meaning. Integration projects therefore budget for interface mapping rather than assuming plug-and-play. HL7 also publishes CDA, a document-oriented XML standard, and FHIR, the modern API-based successor; most hospitals run a mix rather than a single generation.

ICD-10 (International Classification of Diseases, 10th Revision)

ICD-10 is the World Health Organization's classification system that assigns a standard alphanumeric code to each diagnosis, symptom, and cause of death, allowing conditions to be recorded and counted consistently across hospitals and countries.

For an Indian hospital, ICD coding is usually driven by three needs: statutory reporting of morbidity and mortality, insurance and government scheme claims that require a coded diagnosis, and internal analytics such as case-mix review. Coding quality tends to follow whichever of these has the most immediate financial consequence, which in practice means claims.

ICD is a classification, not a clinical vocabulary — it groups conditions into mutually exclusive categories suitable for statistics, and deliberately sacrifices clinical nuance to do so. That is the practical difference from SNOMED CT, which is designed for detailed clinical recording. Mature systems capture clinical detail in one and derive reportable codes from it rather than asking clinicians to think in classification codes. WHO has published ICD-11 as the successor, but ICD-10 remains in widespread operational use.

Interoperability

Interoperability is the ability of two or more health information systems to exchange data and — crucially — for the receiving system to use that data meaningfully without manual re-entry or reinterpretation.

The distinction that matters in procurement is between syntactic and semantic interoperability. Syntactic means the receiving system can parse the message. Semantic means it also understands it: that a value labelled as a serum creatinine result lands in the renal function section of the chart with the right units and reference range, rather than as an untyped attachment a clinician has to open and read. A vendor can honestly claim interoperability while delivering only the former.

Buyers get more useful answers by asking for specifics than by asking whether a system is interoperable. Which standards and versions? Which code systems for labs and diagnoses? Is there a documented API, and is it available on the contracted plan or an extra? Has the vendor completed ABDM milestones, and can they show a working integration at a comparable facility?

LOINC (Logical Observation Identifiers Names and Codes)

LOINC is a freely available coding system that assigns universal identifiers to laboratory tests, clinical measurements, and other observations so that results from different laboratories can be compared and combined.

Every laboratory names its tests locally. One hospital's "FBS", another's "Glucose, fasting", and a third's "Blood sugar (F)" are the same measurement, and without a shared code no system can trend them together across providers. A LOINC code pins down what was measured, on what specimen, by what method where relevant, and in what units — enough for a receiving system to file the result correctly.

The work in adopting LOINC is a one-time mapping exercise: the laboratory's test master is mapped to LOINC codes, and that mapping is then maintained as the test menu changes. Hospitals exchanging diagnostic reports over ABDM need this mapping in place, since a FHIR DiagnosticReport carrying only local test names is technically valid and practically useless to the receiver.

SNOMED CT (Systematized Nomenclature of Medicine — Clinical Terms)

SNOMED CT is a comprehensive, structured clinical terminology that provides codes for diagnoses, findings, procedures, body structures, and organisms, designed for recording clinical detail in electronic health records rather than for statistical classification.

SNOMED CT is far larger and more expressive than a classification like ICD-10. It is hierarchical and post-coordinable, meaning concepts relate to one another formally — a system that knows a recorded finding is a type of pneumonia can retrieve it when a clinician searches for lower respiratory tract infection, without anyone having tagged it twice. That is what makes structured clinical search and decision support possible.

India is a member of SNOMED International, and use of SNOMED CT within the country is covered by a national licence administered through the health ministry's terminology centre, which removes the per-organisation licensing cost that applies in non-member countries. For hospitals the practical adoption route is not to expose the full terminology to clinicians but to use curated subsets behind familiar pick-lists.

Compliance & regulation

Privacy laws, accreditation frameworks, national health networks, and the access-control and audit controls hospitals are expected to demonstrate.

ABDM (Ayushman Bharat Digital Mission)

ABDM is the Government of India's national programme, implemented by the National Health Authority, to build a federated digital health infrastructure consisting of health identifiers, facility and professional registries, and consent-based exchange of health records.

ABDM is deliberately federated: it does not create a central national database of patient records. Records stay with the hospital, clinic, or lab that generated them, and the national infrastructure provides identity, a directory of participants, and a consent-managed gateway that brokers requests. This is a significant architectural point during vendor evaluation, because it means a compliant system must be able to serve records on demand, not merely upload them somewhere once.

Its main building blocks are ABHA for patient identity, the Health Facility Registry and Healthcare Professionals Registry for provider identity, the consent framework for authorisation, and the Unified Health Interface for service discovery and booking. Software vendors integrate by completing published milestones in the ABDM sandbox before being certified for production. Hospitals should ask which milestones a vendor has actually cleared rather than accepting a general claim of ABDM readiness.

ABHA (Ayushman Bharat Health Account)

An ABHA is a 14-digit health account number issued under ABDM that gives an individual a unique identifier for linking and sharing their health records across participating providers.

The number can be created by the individual through official channels or generated at a facility during registration, typically using a mobile number or Aadhaar-based verification. Its purpose is identity resolution: when a patient presents at a new hospital, an ABHA lets that hospital request the patient's prior records from other providers rather than starting from a blank history and a re-taken set of investigations.

Front-desk handling determines whether ABHA delivers value or friction. Capture should be optional and quick — a patient who does not have one, or does not want to share one, must still be registrable in seconds. Hospitals also need to decide how an ABHA maps onto the internal patient identifier, since the ABHA is a linkage key and not a replacement for the hospital's own medical record number.

ABHA address

An ABHA address is a self-declared, human-readable identifier in the form username@abdm that a patient uses to sign in to ABDM services and to receive and share health records, and it is distinct from the 14-digit ABHA number.

The two identifiers are frequently confused at registration desks. The ABHA number is a numeric identifier; the ABHA address is an addressable handle, closer in spirit to an email address, and one person can hold more than one. Consent requests and record-sharing notifications are directed to the address, so staff who record only the number sometimes find that sharing flows do not reach the patient.

Practically, registration staff should be trained to recognise both formats and the software should accept either in the same field, resolving which is which rather than requiring the patient to know the difference. Error messages that say only "invalid ABHA" are a common source of queue delays at busy outpatient counters.

AERB eLORA

eLORA (e-Licensing of Radiation Applications) is the Atomic Energy Regulatory Board's online system through which an Indian hospital registers itself, declares its radiation-emitting equipment, nominates a Radiological Safety Officer, and obtains and renews the licences those machines require.

eLORA is the only channel through which a hospital transacts with AERB about X-ray, CT, cathlab, nuclear medicine and radiotherapy installations. If a machine does not appear in the institute's eLORA account, the regulator does not treat it as a legally commissioned installation, whatever the purchase invoice says. Licences attach to premises rather than to a brand, so a group running three sites generally needs three institute registrations rather than one.

The system is a registry and a transaction portal, not a reminder engine. It will not warn that a CT licence lapses in six weeks, that the only approved Radiological Safety Officer resigned in March, or that a mobile X-ray unit which arrived as a demonstration piece was never declared. RSO approval is also tied to a category of practice, so a hospital adding a cathlab or PET-CT to an existing diagnostic radiology footprint should check that its current approval covers the new class before the launch date is committed.

Audit trail

An audit trail is a tamper-resistant, time-stamped record of who accessed or changed which data in a system, retained so that access to patient information can be reconstructed and reviewed after the fact.

For a hospital the audit trail is what turns an access-control policy into something demonstrable. It answers the questions that arise after an incident: which user opened this celebrity patient's chart, who amended this discharge summary after it was finalised, who exported this list of patient contact numbers, and when. Its usefulness depends on completeness — a log that records logins but not record views cannot answer any of those.

Two design points matter more than log volume. First, the trail must be immutable to the people it records, including administrators, or its evidentiary value collapses. Second, it must be searchable by patient and by user, because both directions of enquiry occur in real investigations. Accreditation assessors and data protection obligations both expect the trail to exist and to be reviewable; retention periods should be set deliberately rather than left at a vendor default.

Biomedical waste (BMW)

Biomedical waste is waste generated during diagnosis, treatment, or immunisation of patients or in related research, which in India is segregated at the point of generation into colour-coded categories and handled under the Bio-Medical Waste Management Rules, 2016.

Segregation is the control that everything else depends on, and it happens at the bedside rather than at the collection point — waste placed in the wrong bag cannot be reliably corrected downstream. The 2016 Rules define colour-coded streams: yellow for anatomical, soiled, and cytotoxic waste and expired medicines, red for contaminated recyclable plastics, white for sharps, and blue for glassware and metallic implants. Cytotoxic and expired drugs are returned to the manufacturer or sent to a common facility for incineration rather than disposed of with general waste.

Administratively the recurring obligations are authorisation from the State Pollution Control Board, a written record of quantities handed to the common treatment facility, staff training and immunisation records, and an annual return. The most useful operational metric is waste weight per occupied bed-day by ward, because it makes segregation failures visible: a ward generating twice the yellow-bag weight of a comparable ward is usually putting general waste into yellow bags, and that is a real recurring cost. The opposite pattern — implausibly low infectious waste for the procedures performed — is the more serious finding.

Data residency

Data residency refers to the physical or geographic location where an organisation's data is stored and processed, and to the contractual and regulatory constraints on moving it outside that location.

Indian hospitals typically ask for patient data to remain on infrastructure located in India. The reasons are partly regulatory and partly practical: domestic hosting simplifies responses to lawful requests, reduces latency for users, and avoids arguments about which jurisdiction governs a breach. Cloud providers offer Indian regions, so the question for a SaaS vendor is not whether it is possible but which region the tenant is actually provisioned in.

Residency deserves attention beyond the primary database. Backups, disaster-recovery replicas, log aggregation, analytics pipelines, error-monitoring services, and support tooling all touch data and are frequently hosted elsewhere by default. A residency commitment that covers the production database but not the backup or the support desk's screen-sharing recordings is incomplete, and this is worth pinning down in writing before signature.

DPDP Act (Digital Personal Data Protection Act, 2023)

The Digital Personal Data Protection Act, 2023 is India's general data protection law, which governs how organisations collect, process, and protect digital personal data and grants individuals rights over their own data.

The Act uses its own vocabulary. The individual is the data principal; the organisation that determines why and how data is processed is the data fiduciary; an organisation processing on a fiduciary's behalf is a data processor. A hospital is the fiduciary for its patients' data, and a hospital software vendor is generally the processor — which means the hospital retains primary accountability regardless of what the software does, and the arrangement should be documented in the contract.

Core obligations include processing personal data for a lawful purpose with notice and, in most cases, consent; limiting collection to what is necessary; keeping data accurate; implementing reasonable security safeguards; reporting personal data breaches; and honouring principals' rights to access, correction, and erasure. Enforcement detail and timelines come through rules made under the Act, so hospitals should track the current rules rather than treating the 2023 text as the whole picture. Practically, the near-term work is a data inventory, retention policy, role-based access, breach response runbook, and vendor agreements.

Form F (PC-PNDT)

Form F is the statutory record completed for every ultrasonography performed on a pregnant woman under India's Pre-Conception and Pre-Natal Diagnostic Techniques Act, capturing the woman's details, the indication, the procedure and result, and signed declarations that foetal sex was neither sought nor disclosed.

A Form F is generated by every scan on a pregnant woman, whatever the clinical reason — a routine growth scan, a presentation check, or an incidental finding of pregnancy during an abdominal scan for pain. Facilities that believe the form applies only to what they regard as a genetic indication are working from a misunderstanding. The completeness standard is absolute rather than substantial: a form with an unsigned declaration is not a partly complete form, it is a defective record.

The reason this matters more than ordinary documentation compliance is that PC-PNDT (frequently written PCPNDT) is criminal law. Contravention exposes the performing practitioner and the owner of the facility to imprisonment and fine under Section 23, and a conviction can reach the practitioner's registration with the state medical council. The commonly checked omissions are a blank or abbreviated indication, the number and sex of existing living children left unstated, a last menstrual period inconsistent with the reported gestational age, and a missing signature on the retained copy. Facilities also register in Form A, hold the resulting Form B certificate, and must keep the registration current when a machine moves or a new sonologist joins the rota.

HFR (Health Facility Registry)

The Health Facility Registry is the ABDM directory of health facilities in India — hospitals, clinics, laboratories, diagnostic centres, and pharmacies, across both public and private sectors — each holding a unique facility identifier.

Registration is a prerequisite for participating in ABDM record exchange, because the registry is how the network knows a requesting or responding facility is a real, identified entity. The facility record covers ownership, type, location, and the services offered, and it is the anchor to which a hospital's health information provider and user roles attach.

Multi-site groups should plan the registration structure before starting. Each physically distinct facility generally needs its own entry, which has downstream implications for how records are attributed and how a network reports across sites. Getting this wrong is tedious to unwind once records have been linked against the identifiers.

HIP / HIU (Health Information Provider / Health Information User)

In the ABDM architecture, a Health Information Provider is an entity that holds patient health records and serves them on request, while a Health Information User is an entity that requests and receives those records under a valid consent.

Most hospitals are both. The hospital acts as a provider when another facility requests a discharge summary it generated, and as a user when it requests a patient's prior lab reports from a diagnostic chain. The two roles are registered and integrated separately, and a vendor may support one before the other — worth confirming, because a system that can only receive records adds little to a hospital's own record-sharing obligations.

The provider role carries the heavier operational burden. It requires the hospital's system to remain reachable, locate records for a given patient linkage on demand, filter them to the consented scope, and respond within the network's expected time. That is a live-availability commitment, not a batch upload, and it should be reflected in how the system is hosted and monitored.

HPR (Healthcare Professionals Registry)

The Healthcare Professionals Registry is the ABDM directory of verified healthcare practitioners in India, covering modern medicine and other recognised systems, with each enrolled professional holding a unique identifier.

The registry links a practitioner to their verified qualifications and council registration, which matters wherever the identity of the treating clinician needs to be trustworthy to a third party — teleconsultation, e-prescription, and records shared beyond the issuing hospital. It reduces reliance on a name and a stamp as the only evidence that a prescription came from a registered practitioner.

For hospitals the practical step is to capture the HPR identifier in the staff master alongside internal payroll and department data, and to keep it current as clinicians join and leave. Visiting and consultant arrangements, which are common in Indian private hospitals, need the same treatment as full-time staff.

Incident reporting

Incident reporting is the hospital process by which staff record patient-safety events — near misses, no-harm incidents, adverse events, and sentinel events — into a system that triages, investigates, and feeds findings back, usually on an explicitly non-punitive basis.

Four categories cover almost everything and staff must be able to place an event without deliberating. A near miss could have caused harm but did not reach the patient, usually because it was intercepted. A no-harm incident reached the patient without detectable injury. An adverse event caused harm. A sentinel event involves death or serious injury, or the clear risk of it, and demands immediate response regardless of outcome. Near misses are the category worth defending hardest, because they are the free lessons — a pharmacist intercepting a tenfold paediatric dose has revealed a system weakness at no cost to a patient.

The number on the dashboard measures willingness to report, not how safe the hospital is. A 200-bed hospital receiving three or four reports a month has a reporting problem, not a low error rate, so rising volumes are a good sign in the first years of a functioning programme and the board metric should be framed as reporting rate. The two design decisions that determine uptake are form length — aim for something completable in under three minutes, asking what happened rather than why — and the feedback loop, since staff stop reporting into a system that never visibly changes anything.

MLC (Medico-Legal Case)

MLC is the standard abbreviation in Indian hospital and medical records for a medico-legal case: a case the hospital registers when the injury or condition may require investigation by law enforcement — assault, accidents, burns, poisoning, suspected self-harm, alleged sexual assault, custodial and unidentified patients — triggering statutory intimation to the police and a heightened documentation standard.

The categories that must be registered should be written down and unambiguous, because leaving the decision to individual judgement produces inconsistency across shifts and doctors. The broadly recognised list covers injuries where foul play is suspected or alleged, vehicular and industrial accidents, burns, poisoning and suspected poisoning, suspected suicide attempts, alleged sexual assault, custodial cases, unidentified or unconscious patients brought without a clear history, unnatural or suspicious deaths, and cases brought in by the police. Where a case is borderline, the operating principle is to register: an unnecessary registration creates paperwork, a missed one creates a serious problem for the hospital and the doctor.

An MLC record is best understood as evidence that happens to be clinical rather than a clinical note that happens to be legally relevant, because it will be read years later by people who were not present and who are professionally motivated to find its weaknesses. That makes contemporaneity, attribution, internal consistency, and chain of custody the properties to design around. The MLC procedure in most hospitals runs: register the case and allocate an MLC number, complete the MLC report in the casualty record, intimate the police, issue a wound certificate where one is required, and secure any samples handed over.

Police intimation is a statutory obligation rather than a courtesy and should be a tracked step with a named owner, recorded in a serially numbered, append-only MLC register held separately from the clinical record — a gap in the sequence is a question the hospital will be asked. Sample custody, restricted access to the file, and readiness for a court summons follow from the same discipline. Whether a hospital may levy charges for medico-legal documentation, and at what rate, is set by state rules and local policy rather than nationally, so the tariff should be written down and applied consistently rather than decided at the counter.

NABH (National Accreditation Board for Hospitals & Healthcare Providers)

NABH is the accreditation body for healthcare organisations in India, operating under the Quality Council of India, which assesses hospitals and other providers against published standards for patient safety and quality of care.

NABH assessment is heavily evidence-based. Standards cover access and continuity of care, patient rights, medication management, infection control, human resource management, and information management, and each is assessed against documented practice rather than intent. Much of the preparation burden is producing consistent records — consent forms, medication administration records, incident reports, indicator data — over a sustained period, not just before the visit.

Hospital software helps only to the extent that it captures these as structured data rather than scanned paper. Systems that record indicators continuously, enforce mandatory fields on clinical documentation, and log access make the evidence assembly far less painful. Accreditation is granted to the hospital, never to the software, so any vendor claim of being NABH-certified should be read as support for NABH documentation. Laboratories are separately accredited by NABL, the national board for testing and calibration laboratories.

PHR address

PHR address is the earlier name for what ABDM now calls an ABHA address — the self-declared, human-readable handle in the form username@abdm that a patient uses to sign in to ABDM applications and to receive and share health records.

The two names refer to the same thing. Personal Health Record address was the term used in earlier National Digital Health Mission material and it persists in older documentation, some consumer applications, and a good deal of staff vocabulary, which is why registration desks still meet patients who say they have a PHR address rather than an ABHA address. Software should treat the terms interchangeably rather than requiring the patient to know which era their terminology comes from.

What it is not is the 14-digit ABHA number. The number is an identifier that answers who this person is and is the right key for deduplication and record linkage; the address is a routing endpoint that answers where records should be sent and from where a consent request should be raised. A patient may hold several addresses over time, or different addresses tied to different applications, while the number stays constant — so linkage logic built on the address alone is fragile.

Quality indicator

A quality indicator is a defined, repeatedly measured metric that a hospital uses to monitor clinical, safety, or operational performance — for example medication error rate, hospital-acquired infection rate, or laboratory redo rate — with a written numerator, denominator, and data source.

Accreditation frameworks including NABH expect a defined set of indicators to be collected continuously rather than assembled before an assessment, and the requirement that carries the real work is the definition itself. An indicator without a written numerator, denominator, inclusion and exclusion criteria, collection frequency, and named owner will be computed differently by different people, and its trend will then reflect changes in counting rather than changes in care.

Departments each carry their own set: CSSD tracks load release and recall readiness, the laboratory tracks turnaround time and redo rates, pharmacy tracks stockouts of vital items, and the wards track falls, pressure ulcers, and medication errors. The useful discipline is to keep the list short enough that each indicator is genuinely reviewed and acted upon. A hospital collecting sixty indicators nobody discusses is doing data entry, not quality management.

RBAC (Role-Based Access Control)

Role-based access control is a security model in which permissions are granted to defined roles rather than to individual users, and users receive access by being assigned to the roles their job requires.

In a hospital this maps naturally onto job function: a front-desk role registers patients and takes payments but cannot view clinical notes; a nurse role records vitals and medication administration for patients on their ward; a pharmacist sees prescriptions but not payroll; a finance role sees revenue but not diagnoses. Managing this at the role level rather than per person is what keeps access correct as staff join, rotate, and leave.

Two failure modes recur. The first is role sprawl — dozens of near-identical roles created ad hoc until nobody can say what any of them permits. The second is the permanent exception, where a user is given broad access to resolve an urgent problem and it is never withdrawn. Periodic access review, with the list of who holds elevated rights actually read by a department head, addresses both. Emergency break-glass access should exist but should be conspicuously logged.

RCA (Root Cause Analysis)

Root cause analysis is a structured retrospective investigation of a patient-safety event that reconstructs what happened, identifies the system conditions that allowed it, and produces corrective and preventive actions — deliberately looking past individual error to the conditions that made the error likely.

The first seventy-two hours are about facts rather than causes, because evidence degrades fast: the infusion pump goes back into circulation, the vial goes into the sharps bin, the case sheet acquires later entries, and memories reorganise around what people have since been told. The immediate response is custodial — sequester the device with its settings and logs intact, retain the vial, tubing and packaging, take a certified copy of the record as it stood including the audit trail, and note the staffing and census for that shift. None of this presumes fault; it preserves the ability to find out.

Keep the panel to four to six people with a trained facilitator, at least one frontline clinician of the same discipline who was not involved, and someone with authority to fund the resulting actions. Those directly involved participate as witnesses and reviewers, never as panel members, because a witness who is also an analyst cannot examine their own decisions freely. Build the timeline before anyone says the word cause: gaps and contradictions between sources are where the useful questions live, and contradictions should be recorded and named rather than resolved in favour of the more plausible account. Actions are then ranked by an action hierarchy — forcing functions and system redesign are durable, retraining and reminders rarely are.

Sentinel event

A sentinel event is an unexpected occurrence involving death or serious physical or psychological injury, or the clear risk of one, which requires immediate investigation and response regardless of whether harm ultimately resulted.

The phrase carries its meaning from the response it triggers rather than from the severity alone: a sentinel event signals a system weakness serious enough that the hospital investigates without waiting to see the outcome. Each hospital should hold a named local list — wrong-site surgery, retained instrument, haemolytic transfusion reaction from an incompatible issue, infant abduction or discharge to the wrong family, suicide of an inpatient — so that staff are not asked to make the classification judgement under pressure at the moment of reporting.

Sentinel events sit at the top of the four-category reporting scale alongside near misses, no-harm incidents, and adverse events, and they are the one category with an immediate rather than 24-hour reporting window. The expectation after registration is a root cause analysis with corrective and preventive actions that are verified as effective rather than merely closed, and accreditation assessors generally ask to see that closure evidence rather than the incident count.

Clinical records & workflows

Terms covering how care is documented and ordered — health records, prescriptions, medication administration, discharge documentation, and remote consultation.

Ambient clinical documentation

Ambient clinical documentation in healthcare is the use of software — commonly called an ambient AI scribe or ambient medical scribe — that listens to a clinical encounter, transcribes it, and produces structured draft notes for the clinician to review, correct, and sign.

The word carrying all the weight is draft. What the system produces is a proposal about what was said; what enters the record is what the clinician verifies and attests to. This is not a legal technicality: ambient tools generate text that reads fluently and confidently whether or not it is accurate, which makes review harder rather than easier. A garbled transcription is obviously wrong, but a plausible, well-formed sentence describing an examination finding that was never stated is not.

The benefit is clearest in verbal, narrative, repetitive encounters — outpatient consultations, follow-up reviews, admission histories — where much of the documentation effort is transcribing a conversation that has just happened. Clinician-in-the-loop review is the entire safety control, so it should be designed rather than assumed: review immediately after each patient is materially more reliable than review at the end of a clinic list, and interfaces should support verification by surfacing the source segment beside each generated statement and flagging medications, doses, allergies, negations, and numbers for explicit confirmation. In India, recording a consultation also brings the encounter within DPDP consent obligations, so notice and consent, retention of the audio, and the vendor's processing location are procurement questions rather than afterthoughts.

Antibiogram

An antibiogram is a periodic summary of the antimicrobial susceptibility of organisms isolated at a given hospital, expressed as the percentage of isolates of each organism that tested susceptible to each agent, and used to guide empirical therapy before culture results are available.

Its purpose is local. National or published susceptibility patterns describe a different population with a different antimicrobial exposure history, and empirical choices made from them are frequently wrong in the places that matter. A hospital antibiogram tells the clinician starting treatment tonight what has actually been working in this hospital, which is the question they are really asking.

The conventions that keep it honest are worth stating: include only the first isolate per patient per period so that a single heavily sampled patient does not distort the percentages, set a minimum isolate count below which a percentage is not reported at all, and separate units where the flora genuinely differ — intensive care from general wards, and where volumes allow, paediatrics from adults. Publishing a susceptibility figure derived from six isolates invites confident decisions the data cannot support.

CPOE (Computerized Provider Order Entry)

CPOE is the practice of clinicians entering medication, laboratory, imaging, and procedure orders directly into a computer system rather than writing them on paper for someone else to transcribe.

The acronym is expanded as both provider and physician order entry; the meaning is the same. Its primary safety benefit is eliminating transcription — the handwritten order that a ward clerk or pharmacist has to interpret, where a misread decimal place or a look-alike drug name becomes a medication error. A secondary benefit is that orders arrive at the receiving department instantly and in a queue, rather than travelling on paper.

CPOE succeeds or fails on the ordering interface. If entering a routine admission order set takes materially longer than writing it, clinicians route around the system and it degrades into retrospective data entry by junior staff, which reintroduces the transcription risk it was meant to remove. Order sets, sensible defaults, and fast search are not conveniences here; they determine adoption.

Crossmatch

A crossmatch is the pre-transfusion compatibility test in which a specific unit of donor blood is tested against the intended recipient's sample to confirm that no reaction is expected before the unit is issued.

Crossmatch sits at the end of a chain that begins with patient sample collection and ABO and Rh typing, and it is unit-specific: it certifies one particular bag for one particular patient, and reserving that unit for that patient is part of the result. The corresponding risk is misidentification at collection or at the bedside, which no laboratory test can catch — which is why sample labelling and bedside verification are treated as part of the transfusion process rather than administrative overhead.

In software terms the blood bank module needs to hold the link between patient, request, crossmatch result, reserved unit, issue, and transfusion outcome, with expiry of the reservation handled automatically so held units return to available stock. Emergency issue of uncrossmatched group O units is a legitimate pathway that should be supported explicitly and logged, not forced through as an exception.

Discharge summary

A discharge summary is the clinical document issued when a patient leaves inpatient care, recording the reason for admission, findings, treatment given, condition at discharge, medications to continue, and follow-up instructions.

It is the handover document to whoever cares for the patient next — the referring physician, the family doctor, or the patient themselves. Its usefulness is judged by whether that reader can act on it without phoning the hospital, which means the medication list and the follow-up plan are the sections that carry the most weight in practice, ahead of the narrative of the admission.

Two operational problems dominate. Timeliness: summaries dictated days after discharge delay billing, frustrate patients waiting at the counter, and lose detail. Consistency: free-text summaries typed from scratch by whoever is on duty vary enormously. Generating the summary from data already captured during the admission — diagnoses, procedures, the active medication list — addresses both, and produces a document that can be shared as a structured record over ABDM rather than only as a printout.

E-prescription

An e-prescription is a prescription created and issued electronically by a registered practitioner, carrying structured drug, dose, route, frequency, and duration data rather than existing only as handwriting or a scanned image.

The value is in the structure. Once dose and frequency are discrete fields, the system can check for duplicate therapy and recorded allergies, the pharmacy can dispense against the order without re-keying it, and the medication list on the chart stays current. A PDF of a typed prescription looks modern but is functionally still paper — this distinction is worth probing during demonstrations.

In India teleconsultation prescribing operates under the national telemedicine practice guidelines, which set out how a registered practitioner may prescribe remotely and which categories of medicine are permitted. ABDM defines a prescription record type as a FHIR bundle, so a hospital already capturing structured prescriptions is well placed to share them; one storing images is not.

EHR (Electronic Health Record)

An electronic health record is a longitudinal digital record of a patient's health that is designed to be shared across the different providers and settings involved in that patient's care, rather than confined to one practice.

The defining characteristic is scope. An EHR is built on the assumption that the patient will be seen elsewhere — by a specialist, a diagnostic centre, another hospital — and that the record should follow them. That assumption drives the technical requirements: standard identifiers, coded data, consent management, and export in interchange formats such as FHIR. A system that cannot get data out cleanly is not fulfilling the EHR premise regardless of what it is called.

In the Indian market the term is used loosely, and most hospital systems sold as EHRs are closer to an EMR with an ABDM interface bolted on. That is not necessarily wrong for a single-site hospital, but the distinction matters for a network intending to share records across branches or with external providers. HealUDoc's clinical record is built to carry a patient's history across departments and branches on one platform.

EMR (Electronic Medical Record)

An electronic medical record is the digital clinical record maintained by a single practice or hospital for its own patients, functioning as the electronic equivalent of that organisation's paper chart.

The contrast with an EHR is boundary, not quality. An EMR can be excellent — rich documentation, order entry, decision support — while remaining organisation-scoped: it is the hospital's chart of what the hospital did. When the patient is referred elsewhere, the usual transfer mechanism is a printed summary rather than a record the receiving system can consume.

For a single-site hospital or clinic with no near-term intention to exchange records, an EMR is often the honest requirement, and it is cheaper and faster to implement well. The reason to care about the distinction is future cost: retrofitting standards-based export and consent onto a system that stores clinical content as unstructured text or scans is expensive, and ABDM participation makes that retrofit likely rather than hypothetical.

MAR (Medication Administration Record)

A medication administration record is the record of each dose of each medication actually given to an inpatient, documenting drug, dose, route, time, and the person who administered it.

The MAR is distinct from the prescription. The prescription is what was ordered; the MAR is what was given, and the gap between them — doses withheld, refused, delayed, or given late — is clinically significant and is exactly what an accreditation assessor or an incident review looks at. Omissions recorded honestly are more useful than a chart with no gaps.

Electronic MARs help by presenting the due list per patient per round, timestamping administration at the point of care, and flagging missed doses rather than leaving them to be noticed. The common implementation failure is deploying an eMAR on ward computers rather than at the bedside, which pushes nurses back to writing on paper and transcribing later — reintroducing the transcription error the system was meant to remove.

Medication reconciliation

Medication reconciliation is the formal comparison of the medicines a patient was already taking against those ordered at a transition of care — admission, transfer, or discharge — so that unintended omissions, duplications, and dose changes are identified and resolved before they reach the patient.

Transitions are where medication lists diverge, and the divergence is usually silent. A patient admitted for something unrelated has their long-term antihypertensive omitted from the admission orders; at discharge the omission is carried forward into the discharge prescription and becomes permanent. The control is a structured best-possible medication history taken at admission from more than one source — the patient or carer, the containers they brought, and previous records — rather than a list copied from the last encounter.

The output that matters is the discharge medication list, because it is what the patient and their next clinician actually act on. It should state, for every medicine, whether it is continued, stopped, changed, or newly started, and say why for anything that changed. A discharge summary listing only the new medicines leaves the patient to reconcile the rest themselves, which is the moment most reconciliation errors become clinical events.

Patient portal

A patient portal is a secure, patient-facing interface — typically a web application or mobile app — through which patients can view their own health information and use services their provider has enabled, such as appointment booking and report access.

The features that actually get used in Indian hospitals are narrow and predictable: viewing and downloading diagnostic reports, booking or rescheduling appointments, seeing prescriptions, and paying bills. Portals that launch with a wide feature set and no attention to these tend to see low repeat use, and the front desk absorbs the calls the portal was meant to prevent.

Two design decisions determine adoption. Authentication must be reachable for patients who do not maintain email — mobile-number-based verification is usually the practical answer. And release rules for results need thought: some findings should reach the patient through a clinician rather than as a portal notification, so hospitals commonly configure a hold period or restrict certain categories.

Teleconsultation

A teleconsultation is an individual clinical consultation conducted remotely between a registered practitioner and a patient using video, audio, or text, in place of an in-person visit.

It is the specific encounter; telemedicine is the broader field it sits within. Operationally a teleconsultation still needs everything an outpatient visit needs — an identified patient, a booked slot, a documented encounter, a prescription where applicable, a bill, and a record on the chart. Treating it as a video call arranged over messaging leaves the hospital with revenue and documentation gaps.

India's national telemedicine practice guidelines set out how registered practitioners may consult and prescribe remotely, including patient identification, consent, record-keeping, and restrictions on which categories of medicine may be prescribed. Hospital systems should record the consultation mode on the encounter, because the applicable rules and the billing treatment can both differ from an in-person visit.

Telemedicine

Telemedicine is the delivery of healthcare services at a distance using information and communication technology, covering remote consultation, diagnosis, treatment guidance, monitoring, and clinician-to-clinician advice.

The field is broader than patient video calls. It includes teleradiology, where images are reported by a radiologist elsewhere; remote intensive-care support; store-and-forward workflows where images or ECGs are sent for asynchronous opinion; and remote monitoring of chronic conditions. Several of these are more commercially established in India than direct-to-patient consultation, particularly teleradiology.

The recurring implementation questions are the same across models: how the remote clinician is identified and credentialed, where the record of the interaction is stored, how the patient's identity is confirmed, and how the service is billed. Systems that treat remote encounters as first-class encounters rather than as attachments to an in-person visit handle these more cleanly.

Triage

Triage is the process of rapidly assessing arriving patients and assigning each a clinical priority, so that treatment order is determined by urgency rather than by arrival time.

Emergency departments generally work to a banded scale — immediate, very urgent, urgent, standard, non-urgent — with a target time to first clinical assessment attached to each band. What makes a scale work is that the assignment is reproducible: two trained nurses seeing the same patient should reach the same band. That comes from criteria tied to observable discriminators such as airway compromise, haemodynamic instability, level of consciousness, pain severity, and mechanism of injury, rather than from general impression.

A digital triage workflow has to record the band, the time of assessment, the observations behind it, and the assessor at the moment of triage, and record re-triage too. Patients deteriorate in waiting rooms, and a system that captures only the initial band cannot show that anyone looked again. Digitally, the value is a live queue ordered by clinical priority and waiting time together, visible to the whole department, with escalation when a patient in any band passes their target — which is also the evidence base for staffing the department.

Hospital operations & systems

Department-level systems and the metrics administrators use to run them, plus the vocabulary of software deployment, migration, and go-live.

ABC and VED analysis

ABC and VED analysis is a two-axis classification of hospital pharmacy and store inventory: ABC ranks items by annual consumption value, VED ranks them by clinical criticality as vital, essential, or desirable, and the two are combined into a matrix that sets a different control policy for each cell.

The reason to run both is that they disagree, and the disagreement is the useful part. An expensive item nobody dies without and a cheap item a patient dies without need opposite control policies, and no single-axis min-max rule can express that. ABC is arithmetic on twelve months of issues — quantity issued multiplied by current unit cost, sorted descending, cut at roughly 70% and 90% of cumulative value to give classes A, B, and C. Use issues rather than purchases, since purchases reflect ordering behaviour rather than consumption.

VED cannot be computed, because criticality is a clinical judgement about the consequence of absence. Vital items are those whose unavailability risks death or serious harm with no ready substitute — antidotes, anti-snake venom, resuscitation drugs, oxygen. Essential items cause significant deterioration or force an inferior alternative; desirable items cause inconvenience. The classification must be hospital-specific: an item that is vital where there is a cathlab or a neonatal unit is desirable where there is not, so a VED list copied from a textbook or another hospital is wrong in precisely the places that matter. The combined matrix then drives the policy — AV items get tight buyer attention and a protected buffer, CV items get generous stock because carrying them is cheap and running out is not.

ALOS (Average Length of Stay)

Average length of stay is the mean number of days inpatients remain in hospital, calculated by dividing total inpatient days over a period by the number of discharges in that period.

ALOS is read as an efficiency and throughput indicator, but it is only interpretable alongside case mix. A tertiary hospital taking complex referrals will have a longer ALOS than a day-surgery centre, and that difference says nothing about either one's performance. Meaningful use means comparing ALOS within a specialty or diagnosis group, and watching the trend rather than the absolute figure.

Falling ALOS is not automatically good. If it moves with a rising readmission rate, the hospital is discharging too early and absorbing the cost twice. The operationally useful version tracks ALOS by specialty and consultant alongside readmissions, and separates clinical length of stay from discharge delay caused by pending bills, insurance approvals, or transport — the latter is a process problem with a different fix.

Bed occupancy rate

Bed occupancy rate is the proportion of a hospital's available beds that are occupied over a given period, calculated as occupied bed-days divided by available bed-days and expressed as a percentage.

The formula is: bed occupancy rate = (inpatient bed-days ÷ (available beds × days in the period)) × 100. Worked through for a month: a 200-bed hospital in a 30-day month has 200 × 30 = 6,000 available bed-days. If it recorded 4,800 occupied bed-days, occupancy is (4,800 ÷ 6,000) × 100 = 80%. Occupied bed-days are counted from a daily census taken at a fixed time — midnight is the usual convention — and the census moment must be the same every day, because moving it changes the number without anything changing in the hospital.

The denominator is where most reporting disputes arise. Available beds should mean beds actually staffed and usable, not the sanctioned or licensed count — beds closed for maintenance, or open but unstaffed, inflate the denominator and understate the pressure the hospital is under. Fixing this definition once, in the system, prevents recurring arguments between ward and management figures. Accreditation and NABH-oriented reporting expect the same consistency: state the definition alongside the number.

Very high occupancy is not an unambiguous success. Sustained figures above the low nineties leave no buffer for emergency admissions or infection control isolation, so elective cases get cancelled and patients wait in emergency. Administrators generally watch occupancy by ward and by day of week, since an overall figure conceals a full ICU alongside empty general beds. Read it alongside average length of stay: the same occupancy figure means something quite different when it comes from many short admissions than from few long ones.

CSSD (Central Sterile Services Department)

The central sterile services department is the unit that decontaminates, inspects, assembles, packs, sterilises, stores, and issues reusable surgical instruments and sets for the whole hospital, and its throughput sets the practical ceiling on how many procedures the operating theatres can run.

CSSD sterilisation (US: sterilization) is a one-way process, and the physical layout should enforce that direction: instruments move from the dirty receiving and decontamination zone, through a barrier, into clean inspection, assembly and packing, into the sterilisers, and out into sterile storage and issue. Any point where clean items pass back through a dirty area is a design defect rather than a workflow inconvenience. Cleaning is the stage later stages cannot rescue — sterilisation does not compensate for inadequate cleaning, because organic residue physically shields organisms from the sterilant, and an instrument entering the autoclave with residue in a lumen leaves with that residue sterilised in place.

Two records carry most of the operational weight, and CSSD record keeping is what a tracking system exists to make reliable. The set composition list is a controlled document rather than something held in the memory of a senior technician, and each set should be assembled against a count sheet with the assembler identified. Load records tie every tray to the cycle that produced it and to the patients who received instruments from it, which is what makes a recall possible — set-level tracking is sufficient for that and is the minimum for any hospital performing invasive procedures, while instrument-level tracking answers finer questions at real additional cost. Release of a load depends on cycle parameters plus chemical and biological indicators, and CSSD quality indicators typically cover load release turnaround, recall readiness, set-shortage incidents, and re-processing rates.

CSSD software is generally bought either as a module of the hospital management system or as a standalone tracking system, and the distinction that matters at evaluation is whether it links loads to patients without manual reconciliation — that link is the whole basis of a recall. CSSD planning for a new or expanding department works backwards from theatre demand: the number of sets each list consumes, the turnaround each set needs, and therefore the steriliser capacity, washer capacity, and set inventory required to keep theatres running without borrowing trays between lists.

Data migration

Data migration is the process of extracting data from a hospital's existing systems, spreadsheets, or paper records, transforming it to fit the new system's structure, and loading it so that historical information remains usable after the change.

Scope should be decided explicitly rather than by default. Patient demographics, outstanding balances, active inpatients, item and tariff masters, and staff records are almost always needed on day one. Full clinical history frequently is not, and attempting it can delay a go-live by months for records that will rarely be opened. A common compromise is migrating structured masters and recent activity while retaining read-only access to the legacy system for older history.

Migration exposes data quality that the old system tolerated: duplicate patient records, inconsistent phone number formats, items with no price, staff who left years ago. Cleaning is unavoidable, and it is the hospital's staff who must adjudicate it since only they know which of two records is the real patient. Budget for at least two trial migrations before the real one, with the hospital verifying record counts and sample records itself rather than accepting the vendor's word.

Deduplication

Deduplication is the identification and merging of multiple records that refer to the same real-world entity — most often the same patient registered more than once — into a single authoritative record.

Duplicate patient registrations are near-universal and arise honestly: the patient gives a different phone number, the name is spelled differently, a walk-in is registered in a hurry rather than searched for. The consequence is a split history, so a clinician sees only part of the picture and the hospital repeats investigations it has already done and paid for.

Control has two halves. Prevention is a fast, forgiving search at registration — matching on partial name, phonetic variants, mobile number, and date of birth — so finding an existing patient is easier than creating a new one. Remediation is a periodic review of probable-duplicate candidates and a merge function that combines encounters, results, and balances while retaining an audit record of the merge, since merges are occasionally wrong and must be reversible.

Deployment model (on-premise vs cloud/SaaS)

A deployment model describes where hospital software runs and who operates it — on servers the hospital owns and maintains inside its own premises, or on infrastructure operated by the vendor and delivered as a subscription service over the internet.

On-premise gives the hospital physical control and continued operation during an internet outage, but transfers responsibility for servers, backups, patching, security, and upgrades to the hospital or its IT contractor. In practice that responsibility is often under-resourced, and the most common failure mode is an on-premise system running years-old software on an unpatched machine with backups nobody has tested restoring.

Cloud or SaaS shifts that operational load to the vendor and makes multi-branch access straightforward, at the cost of a hard dependency on connectivity and on the vendor's competence. Hospitals choosing SaaS should establish where data is hosted, what the availability commitment is, what happens during an internet outage, and how data is exported if the relationship ends. Hybrid arrangements — cloud primary with a local read-only cache for critical screens — exist but add complexity that only larger sites usually justify.

Downtime procedure

A downtime procedure is the documented, rehearsed set of manual fallbacks a hospital uses to keep treating patients when its information systems are unavailable, together with the process for reconciling records once systems return.

A hospital cannot stop admitting or treating because software is down, so the procedure has to cover the small number of things that genuinely cannot wait: registering and identifying a patient, ordering and reporting urgent investigations, issuing and administering medication, and issuing blood. This usually means pre-printed forms held on each ward, a current patient census printed on a schedule, and a named person authorised to declare downtime.

The half that gets neglected is recovery. Everything recorded on paper during the outage has to be entered afterwards, and if that is not assigned and scheduled, the electronic record silently develops a gap covering exactly the period when things were going wrong. Procedures should be tested during planned maintenance windows rather than first attempted during a real outage.

Go-live

Go-live is the point at which a hospital begins using a new system for real operational work, ending parallel running or legacy use and making the new system the system of record.

Two strategies are common. A big-bang go-live switches every department at once, which avoids sustained double entry but concentrates all risk on one date. A phased go-live starts with registration and billing, then adds clinical, diagnostics, and pharmacy, which is gentler but requires interim workarounds while systems coexist. Mid-sized Indian hospitals more often phase, with outpatient registration and billing first because the workflows are high-volume and comparatively contained.

What separates smooth go-lives from difficult ones is rarely the software. It is whether masters were configured and verified in advance, whether staff were trained on their own workflows rather than given a generic demonstration, whether on-floor support was present for the first weeks at each shift change, and whether the hospital deliberately reduced elective load for the first few days. Command-centre arrangements — a named escalation path per department — are worth setting up before the date, not during it.

HIS (Hospital Information System)

A hospital information system is the integrated software platform that runs a hospital's clinical and administrative operations, typically spanning registration, appointments, outpatient and inpatient workflows, diagnostics, pharmacy, billing, and reporting on shared data.

The defining property is shared data rather than breadth of features. In a genuinely integrated HIS a patient registered once is the same patient in the laboratory, the pharmacy, and the billing counter, and a service ordered clinically appears on the bill without anyone re-entering it. Suites assembled from separately acquired modules often fail this test, and the symptom is staff maintaining registers to reconcile what the software should already agree on.

Evaluation is more informative when it follows a real patient journey end to end — walk-in registration through consultation, investigation, pharmacy, and final bill — rather than reviewing a module checklist. That is where duplicate entry, missing links between order and charge, and awkward departmental handoffs become visible. HealUDoc is built as this kind of single-platform system, with clinical, diagnostic, pharmacy, and finance workflows on one data model.

HIS vs RIS vs PACS

HIS, RIS, and PACS are three distinct systems in an imaging workflow: the hospital information system holds the patient, the order, and the bill; the radiology information system runs the department's scheduling, worklists, and reporting; and PACS stores and displays the images themselves.

Follow one chest CT to see the division of labour. The HIS registers the patient, carries the clinician's order and the patient's identity and billing, and passes the order to the RIS. The RIS schedules the study, puts the patient on the modality worklist so the radiographer does not retype demographics at the machine, and tracks the study through acquisition to a signed report. The scanner sends images to PACS, where the radiologist reads them on a diagnostic workstation; the report is authored against the RIS and returned to the HIS so the referring clinician sees it in the patient's record. The short answer to the common question is that RIS handles orders, scheduling, and reports, PACS handles pixels — they are complementary rather than alternatives, and a hospital doing meaningful imaging volume needs both.

The joins between them are where imaging projects actually fail. Modality worklist integration is a small feature with outsized effect, because manual entry at the machine is the main source of mismatched patient data in the archive. Identity has to be consistent across all three, which in practice means one master patient index rather than three local ones, since a mismatch leaves studies orphaned from the record they belong to. DICOM is the standard governing image and worklist exchange, and HL7 or FHIR typically carries orders and results between HIS and RIS. Where the three are separately procured, agree at contract stage who owns each interface — that ownership gap, rather than any single product, is what most often leaves reports stranded outside the patient record.

HMIS (Health Management Information System)

HMIS refers to a system for collecting and reporting aggregated health service data for management and public health purposes, and in India most specifically to the health ministry's national HMIS portal through which facilities report routine service statistics.

The term is used in two different senses and it is worth clarifying which is meant in any given conversation. In the public health sense, HMIS is the national reporting system: facilities submit periodic aggregate returns on services delivered, which feed district and state-level monitoring. In the commercial sense, Indian vendors frequently market hospital management software as an HMIS, expanding the acronym as hospital management information system.

For a hospital that reports into the national system, the practical requirement is that its operational software can produce the required aggregates from transactional data instead of staff compiling returns by hand from registers. Where the software cannot, reporting is done by manual tally and the numbers rarely reconcile with the hospital's own operational figures.

IPD (Inpatient Department)

The inpatient department covers care for patients formally admitted to hospital and occupying a bed for at least one night, encompassing admission, ward and bed allocation, daily clinical care, transfers, and discharge.

IPD workflow is longer-running and more stateful than outpatient work. A single admission accumulates orders, results, medication administration, consumables, procedures, doctor visits, room charges, and transfers between wards or beds, and the bill is assembled continuously rather than settled at one counter. Charge capture is the usual weak point: services delivered on the ward that never reach the bill are a persistent, quiet revenue leak.

The operational pressure points are bed allocation, interim billing for long stays, insurance pre-authorisation and approval, and discharge turnaround. Discharge in particular is where patients experience the hospital's coordination — or its absence — since the wait between a clinical decision to discharge and the patient actually leaving is usually caused by bill finalisation and approvals rather than by clinical care.

Levey-Jennings chart

A Levey-Jennings chart plots each laboratory quality control result over time against the established mean, with lines drawn at one, two, and three standard deviations, so that analytical performance can be judged as a pattern rather than from any single point.

Its value is pattern recognition. A run of values drifting steadily upward tells you something quite different from one point beyond two standard deviations, even though the single point looks more alarming. The two patterns worth naming are shift — an abrupt move to a new level that then holds, typically a new reagent lot, a recalibration, or a maintenance event — and trend, a gradual movement across successive runs, typically deteriorating reagent, a drifting light source, an ageing electrode, or slowly failing temperature control.

The chart is only as meaningful as the mean and standard deviation behind it. Manufacturer-assigned values on the control insert are a starting point for a new lot rather than a permanent target: they are derived across many instruments and methods and are usually wider than a single laboratory's own performance, so using them indefinitely produces charts that almost never flag anything. The laboratory should establish its own mean and SD from its own data on the specific instrument and method, collected across multiple days so between-day variation is represented, and review them when reagent lot, calibrator lot, or instrument service changes materially. Westgard rules are the decision rules applied to what the chart displays.

LIS (Laboratory Information System)

A laboratory information system manages the clinical laboratory's workflow from order receipt and specimen collection through analyser interfacing, result validation, and report release, along with quality control and laboratory inventory.

The core sequence an LIS controls is order, sample collection with barcoded identification, accessioning, analysis, technical and medical validation, and release. Analyser interfacing matters commercially as well as clinically: an analyser sending results directly into the LIS removes both transcription error and a substantial amount of technologist time, and hospitals should confirm which of their specific instruments a vendor has interfaced before, not merely that interfacing is supported.

An LIS should also handle the parts of laboratory work that are not results: internal quality control with rule-based flagging, reagent stock and expiry, sample rejection with reasons, and turnaround-time measurement by test and by stage. Outsourced or referred-out tests need explicit handling so that the report reaches the same patient chart as in-house work.

MPI (Master Patient Index)

A master patient index is the authoritative directory that assigns each patient a single unique identifier within an organisation and links all of that patient's records across departments and systems to it.

The MPI is what makes one patient one patient. Without it the laboratory, the pharmacy, the radiology archive, and billing each hold their own version of the person, and reconciling them becomes manual. The version spanning multiple facilities in a group is usually called an enterprise MPI, and it is what allows a network to recognise that a patient seen at one branch is the same person presenting at another.

Index quality is measured by its duplicate rate and by the frequency of overlays — the more dangerous error, where two different people end up sharing one record. Preventing both depends on search behaviour at registration and on disciplined merge and unmerge procedures. Where ABHA is captured, it provides an additional matching attribute, but it supplements the internal index rather than replacing it, since not every patient will present one.

NHPPD (Nursing Hours Per Patient Day)

Nursing hours per patient day is the total nursing care hours delivered on a unit over a period divided by the number of patient-days on that unit in the same period, giving the average nursing time each patient received per day.

NHPPD is the workload measure that converts a staffing intention into an auditable number, and it is more informative than a headcount because it absorbs shift length, skill mix, and the difference between sanctioned and actually worked hours. Two decisions determine whether the figure means anything: which staff count towards the numerator — registered nurses only, or nursing assistants and unit clerks as well — and whether the hours are those rostered or those actually worked after leave and absence. Both should be written down, because a hospital comparing its NHPPD with a published figure computed on different rules is comparing nothing.

In practice it is used together with a nurse-to-patient ratio rather than instead of one. The ratio sets a floor per shift that is easy to communicate and audit; NHPPD measures what the unit as a whole actually delivered across the day, which is where relief for weekly offs, annual and sick leave, maternity leave, and training either exists or does not. A unit meeting its ratio on paper while its NHPPD falls month on month is absorbing the gap through individual nurses working longer or covering more beds, and that absorption stays invisible in reports until it surfaces as attrition, incident rates, or an accreditation finding.

Nurse-to-patient ratio

A nurse-to-patient ratio is the maximum number of patients assigned to one nurse on a shift in a given unit — expressed as 1:1, 1:6 and so on — stating the minimum nursing presence a patient can expect on any shift, in any unit, on any day of the year.

Stated that way it becomes clear why a ratio written into a policy manual but never costed into the sanctioned strength is worse than no ratio at all: it creates an expectation the roster cannot meet. The number is the easy part; the difficult part is the arithmetic converting it into funded, filled, and rostered posts including relief for weekly offs, annual leave, sick leave, maternity leave, and training days. Ratios also differ sharply by setting — intensive care is the one place near-continuous bedside presence is genuinely required, high dependency sits a step below, and general wards vary most because the same bed count can hold a very different dependency mix month to month.

A ratio-based model is simple to communicate, audit, and roster against, but treats every patient in a ward as equivalent. An acuity or workload-based model scores each patient against dependency categories and derives required nursing hours from the mix actually present; it reflects reality better but demands that someone classify patients reliably every shift, and if that classification drifts toward whatever justifies the current roster the model becomes theatre. A common compromise uses the ratio as a hard floor and acuity as the escalation trigger. Operating theatres are not staffed by a patient ratio at all but per functioning table per shift, and hospitals that fold OT nursing into a bed-based calculation consistently under-sanction it. WHO and national bodies publish indicative norms, but a defensible ratio comes from measured local workload rather than a number copied from another hospital.

OPD (Outpatient Department)

The outpatient department covers care delivered to patients who are not admitted to a bed, including consultations, follow-ups, minor procedures, and associated investigations completed within the same visit.

OPD is a volume business, and the constraint is almost always the registration and billing counter rather than clinical time. Seconds per transaction multiply across hundreds of patients a day, so search speed, payment handling, and the number of screens between arrival and token issue have a disproportionate effect on queue length and on the hospital's perceived efficiency.

The workflow to design around is the full loop: registration, token or appointment, consultation, investigation, return with reports, and prescription. Systems that handle the first visit well but make the return-with-reports step awkward push patients back into physical queues twice. Follow-up consultation rules — where a review within a defined window carries a reduced or waived fee — should be enforced by the system rather than left to counter staff judgement.

PACS (Picture Archiving and Communication System)

A PACS is the system that stores, retrieves, distributes, and displays medical images, allowing studies acquired on imaging equipment to be archived centrally and viewed on diagnostic workstations rather than printed to film.

PACS handles the images; the radiology information system handles the orders, scheduling, and reports around them. Together they replace film and the film library. The economics are usually straightforward for any hospital doing meaningful imaging volume, since film, chemicals, storage space, and lost-film retakes are real recurring costs, but the storage commitment is long-term and grows continuously.

The specifications worth scrutinising are storage growth and retrieval speed for older studies. Cross-sectional imaging generates large studies, retention obligations run for years, and a design that keeps recent studies on fast storage while moving older ones to cheaper tiers is normal — provided retrieving a five-year-old comparison study still takes seconds rather than a support request. Disaster recovery for the archive deserves the same attention as the clinical database.

RIS (Radiology Information System)

A radiology information system manages the non-image side of a radiology department — order receipt, scheduling, patient tracking, modality worklists, reporting, report distribution, and departmental billing and productivity data.

The RIS is what turns an imaging order into a scheduled appointment, places the patient on the modality worklist so the technologist does not retype demographics at the machine, tracks the study through acquisition and reporting, and delivers the signed report back to the referring clinician. Worklist integration is a small feature with an outsized effect, because manual entry at the modality is the main source of mismatched patient data in the image archive.

Departments evaluate an RIS largely on turnaround time and on report workflow — draft, review, sign, amend — including how amendments are tracked once a report has been distributed. Structured reporting templates and voice recognition are common additions. In hospitals using external teleradiology, the RIS also has to route studies out and bring reports back into the same patient record.

Super user

In a hospital software implementation, a super user is a member of the operational staff who receives deeper training on the system and acts as the first point of help and the departmental voice in configuration decisions.

Super users are not IT staff. They are the experienced registration clerk, the ward sister, the senior pharmacist — people who already know how the department actually works and are trusted by their colleagues. That is what makes them effective: a question answered by a colleague on the floor in thirty seconds does not become a support ticket, and adoption problems surface early rather than at a steering meeting a month later.

The arrangement fails in predictable ways. Nominating someone without reducing their normal workload means the role is performed badly or not at all; nominating only day-shift staff leaves nights and weekends unsupported; and losing one or two super users to attrition after go-live can remove most of a department's system knowledge. Identify at least two per department per shift pattern, and keep them involved after go-live rather than disbanding the group.

System status management (SSM)

System status management is the ambulance-service practice of positioning available vehicles according to predicted demand by time and location, and defining in advance which unit is dispatched and how the remaining fleet redeploys, rather than returning every vehicle to a fixed base between calls.

The premise is that historical call data predicts demand well enough to be worth acting on: call volume varies by hour of day, day of week, and area in patterns that repeat. A status plan turns that into posting locations and shift start times, so that vehicles wait where the next call is likely to come from. The measure it exists to improve is response time distribution — usually the 90th percentile rather than the average, because averages conceal exactly the long waits that matter.

For a hospital-operated fleet the practical version is more modest than a full ambulance-service deployment model, but the same components apply: knowing which vehicles are genuinely available versus committed, crewed, or out for maintenance; a written dispatch rule so the choice is not made ad hoc under pressure; and a move-up plan for what happens to coverage when the nearest unit is committed. The prerequisite for all of it is accurate live status, which is why timestamps for dispatch, en route, on scene, transporting, and at destination are worth capturing properly — a status plan built on stale availability data allocates vehicles that are not there.

TAT (Turnaround Time)

Turnaround time is the elapsed time between the start and completion of a defined process step — commonly from test order or sample collection to report release in diagnostics, or from decision to discharge to the patient actually leaving.

TAT is only comparable when the start and end points are defined and held constant. A laboratory measuring from sample receipt in the lab will report a much better figure than one measuring from the clinician's order, and the difference between the two is exactly the collection and transport delay that patients and clinicians experience. Measuring the full clinician-to-clinician interval is more honest and more actionable.

The useful presentation is a distribution, not a mean. Average TAT hides the tail, and it is the slowest few percent — the delayed critical result, the report that took two days — that generates complaints and clinical risk. Hospitals typically set separate targets for routine, urgent, and critical categories, monitor the proportion meeting each target, and review breaches by stage to find where time is actually lost.

Uptime SLA (Service Level Agreement)

An uptime service level agreement is the contractual commitment a software vendor makes about the percentage of time its service will be available, together with how availability is measured, what is excluded, and what remedy applies if the commitment is missed.

The headline percentage means less than the terms around it. A 99.9 percent commitment allows roughly forty-three minutes of unavailability a month, and 99.5 percent allows about three and a half hours. What matters as much is whether planned maintenance is excluded, how availability is measured and by whom, whether partial degradation counts as downtime, and whether the remedy is a service credit or something more meaningful. For most hospital contracts the remedy is a credit, which does not compensate for a disrupted outpatient session.

Because the financial remedy is usually small, hospitals should treat the SLA as a signal of the vendor's operational maturity and plan independently for the outage that will eventually occur. That means an agreed downtime procedure, a published status and escalation path, and clarity on support hours — a commitment that covers business hours only is materially different for a facility running a twenty-four-hour emergency department.

Westgard rules

Westgard rules are a set of statistical QC rules applied to laboratory internal quality control results — written as 1-2s, 1-3s, 2-2s, R-4s, 4-1s and 10x — which together determine whether an analytical run is accepted and patient results released, or rejected and investigated.

Each rule names a pattern in the control data. 1-3s rejects a run when a single control result falls beyond three standard deviations from the mean, and it catches large random error. 2-2s flags two consecutive results beyond the same two-standard-deviation limit, and R-4s flags a range of four standard deviations between controls within a run; both point to systematic error. 4-1s flags four consecutive results beyond the same one-standard-deviation limit, and the 10x rule flags ten consecutive results falling on the same side of the mean — neither is a large deviation, but both indicate a shift the laboratory should explain. 1-2s is conventionally used as a warning that triggers inspection of the other rules rather than as a rejection rule in its own right, because on its own it produces frequent false rejections.

Rules are chosen to match the test's precision relative to its allowable error, not applied uniformly. A method with generous analytical performance relative to clinical requirements can run 1-3s alone without missing anything important; a method operating close to its limit needs a multirule combination to detect smaller shifts, accepting more investigation in exchange. Applying the full multirule set to every analyte produces rejections that are statistically inevitable rather than clinically meaningful, and a laboratory that repeatedly repeats runs until the control passes has stopped doing quality control. When a rule is violated the run is held, patient results are not released, the cause is investigated, and the run is repeated after correction — and the rules only ever answer whether the analytical process is behaving as characterised. They do not detect errors that occurred before the specimen reached the analyser.

Revenue, billing & payers

Hospital revenue cycle vocabulary — insurers and third-party administrators, government scheme claims, tariffs, denials, daily collections, and clinician payouts.

AB PM-JAY (Ayushman Bharat Pradhan Mantri Jan Arogya Yojana)

AB PM-JAY is the Government of India's publicly funded health assurance scheme, implemented by the National Health Authority, which provides eligible families with cover for secondary and tertiary inpatient treatment at empanelled public and private hospitals.

For an empanelled hospital, PM-JAY is a distinct operational track rather than a variation on cash billing. Treatment is delivered cashless to the beneficiary; the hospital verifies eligibility, obtains pre-authorisation against a defined package, delivers care, and then claims against the scheme's package rate. Package rates are set by the scheme, so the hospital's own tariff does not apply and the margin depends on cost control rather than pricing.

The administrative burden concentrates in documentation. Pre-authorisation, package selection, mandated clinical evidence, and discharge documentation all have to be complete and consistent, and gaps are the usual cause of query and rejection. Hospitals doing meaningful scheme volume generally staff a dedicated team and expect a longer payment cycle than cash or corporate work, which has to be planned for in working capital.

Claim denial

A claim denial is a payer's refusal to pay all or part of a submitted claim, issued with a stated reason such as missing documentation, a service outside policy coverage, an exhausted limit, or a discrepancy between the claim and the clinical record.

Denials divide usefully into two groups. Preventable denials arise from process failures the hospital controls — pre-authorisation not obtained, policy details captured wrongly at admission, documentation missing, a claim filed after the submission window. Non-preventable denials reflect genuine coverage limits. Only the first group is worth investing in, and it is usually the larger.

Managing denials requires reason codes to be recorded consistently rather than as free text, because the pattern is what identifies the fixable process. A hospital that finds a third of its denials trace to one documentation gap at admission has a solvable problem. Denials also need an owner and an appeal deadline, since unworked denials quietly become write-offs, and tracking the eventual recovery rate on appeal shows whether the effort is worthwhile.

Daily closing

Daily closing is the end-of-shift or end-of-day reconciliation in which each collection point balances the cash, card, and digital payments it recorded in the system against what it physically holds and reports, before handing over.

This is the control that keeps billing honest at scale. Each counter closes against its own recorded collections, differences are identified while the transactions are still fresh in memory, and accountability is tied to a named user and shift rather than diffused across a day. Hospitals running multiple counters across outpatient, pharmacy, diagnostics, and inpatient billing need closing to work per counter, not only in aggregate.

Software should make the reconciliation mechanical: a shift summary broken down by payment mode, cancellations and refunds shown explicitly with authorisation, discounts listed with who approved them, and the resulting difference recorded rather than silently absorbed. Discounts and cancellations are where most leakage occurs, and a closing report that shows only a total collected figure will not surface it.

DNFB (Discharged Not Final Billed)

DNFB is the total value of accounts where the patient has been discharged but no final bill has been raised, measured in days as the gross charge value of those accounts divided by average daily gross revenue.

It is the most expensive backlog a hospital can carry, because every amount in it represents cost already incurred and revenue already earned but cash not yet even requested. The arithmetic is straightforward: if a hospital holds ₹1.8 crore of unbilled discharged accounts against average daily gross revenue of ₹30 lakh, DNFB stands at six days. Those figures are illustrative — the method is what transfers. Benchmarks circulate, but the more useful comparison is against the hospital's own trend and against the bill-hold reasons behind the number.

Charges get stuck in a small number of predictable places: late charge capture from ward, theatre, or ancillary departments; a discharge summary or operative note not completed, which blocks coding; coding backlog or a query pending with the consultant; an investigation report not finalised; a payer prerequisite such as a missing pre-authorisation reference, where the account is held deliberately; and interface failures leaving charges unposted. DNFB is managed daily or not at all — a weekly review lets accounts age five days before anyone looks. The working review is fifteen to twenty minutes on exceptions only, sorted by days since discharge, each aged account carrying a hold reason and a named owner, with the same account appearing three days running escalated rather than re-noted.

Doctor payout

A doctor payout is the amount a hospital pays a consultant under their engagement terms — commonly a share of consultation and procedure revenue, a fixed retainer, a per-session fee, or a combination — calculated over an agreed period.

Indian private hospitals typically run several arrangements simultaneously: full-time salaried clinicians, visiting consultants on a revenue share, and per-session or per-procedure engagements. Share percentages often vary by service type, and may differ for outpatient consultation, inpatient visits, procedures, and interpretation of investigations. Calculating this from billing data by hand is slow and disputed, and disputes damage relationships with the consultants a hospital most depends on.

The requirements that make payout calculation reliable are attribution and traceability. Every billable service needs the responsible clinician recorded at the point of billing, not reconstructed later; the rule set needs to handle shared or referred procedures; and the payout statement should be drillable to the underlying bills so a consultant can check their own figures. Handling of discounts, cancellations, and unrecovered credit sales should be agreed in advance, since these are the recurring source of disagreement.

Patient acquisition cost (PAC)

Patient acquisition cost is the total marketing and outreach spend attributable to winning new patients over a period, divided by the number of genuinely new patients acquired in that period — normally computed per specialty rather than for the hospital as a whole.

The hospital-wide figure is close to useless, because the economics differ by an order of magnitude between departments. A dermatology consultation and a cardiac surgery admission have different values, different decision timelines, and different referral dynamics, so averaging their acquisition costs produces a number that describes no actual decision. Computing it per specialty is what makes it a budgeting instrument.

Two definitional choices decide whether the number is honest. The numerator should include everything spent to generate demand — digital spend, camps and screening events, referral arrangements where these are lawful and disclosed, the loaded cost of front-office staff time spent converting enquiries — not just the advertising invoice. The denominator must count genuinely new patients, not visits: counting a returning patient's follow-up as an acquisition makes any campaign look successful. Read alongside expected lifetime value for that specialty, since a high acquisition cost is entirely rational where the patient relationship is long and recurring, and indefensible where the episode is one-off.

RCM (Revenue Cycle Management)

Revenue cycle management is the coordinated administration of every step by which a hospital converts clinical services into collected payment — from registration and eligibility checks through charge capture, billing, claim submission, denial handling, and final collection.

The cycle starts far earlier than most hospitals treat it. Errors introduced at registration — a wrong policy number, an unverified corporate entitlement, a missing pre-authorisation — surface weeks later as a denial, when they are expensive to fix and the patient has gone home. Front-office accuracy is a revenue function, and staffing and training decisions there should be made on that basis.

The measures that reveal how the cycle is actually performing are days in accounts receivable, the proportion of receivables ageing beyond ninety days, first-pass claim acceptance, denial rate by reason, and the value of charges never billed. The last is the hardest to see and often the largest: consumables, procedures, and ward services delivered but never posted to the bill. Systems that generate the charge from the clinical or dispensing action, rather than relying on a separate posting step, close most of that gap.

Tariff / rate contract

A tariff is a hospital's schedule of prices for its services, and a rate contract is a negotiated variant of that schedule agreed with a specific payer — an insurer, third-party administrator, corporate client, or government scheme.

A hospital of any size runs many price lists at once: a cash tariff, separate schedules for several insurers and corporates, government scheme package rates, and often ward-class-linked variations where the same procedure is priced differently by room category. Managing these in spreadsheets is where billing disputes originate, because the counter applies whichever version it has and the payer applies the contract.

The system requirement is that the applicable rate is selected automatically from the patient's payer and class at the point of billing, that effective dates are held so a revised contract applies from the right day, and that overrides require authorisation and are logged. Package or bundled rates need explicit support, since a package that is billed line by line will be reduced by the payer to the package amount and the difference becomes a write-off.

TPA (Third-Party Administrator)

A third-party administrator is an intermediary organisation, licensed by the insurance regulator, that administers health insurance claims on behalf of insurers — issuing cashless authorisations, processing claims, and settling with hospitals.

For a hospital the TPA is the counterparty it actually deals with day to day, even though the insurer carries the risk. The cashless pathway runs through the TPA: eligibility confirmation, pre-authorisation before planned admission or shortly after an emergency one, interim approvals as an inpatient stay extends, and final approval at discharge. Delay at any of these points shows up directly as a patient waiting to be discharged.

Hospitals commonly deal with many TPAs at once, each with its own portal, documentation expectations, tariff, and payment behaviour. The operationally significant metrics are approval turnaround, the share of claims deducted or denied, and days to settlement, tracked per TPA rather than in aggregate — that is what supports both credit control and the next contract negotiation.

Utilisation management (UM)

Utilisation management — also written utilization management — is the review of whether admissions, continued inpatient stays, and procedures meet the clinical criteria a payer will fund, carried out before or during care rather than after the bill is raised.

It exists because the most expensive denial is the one raised against care already delivered. A stay that a payer regards as not meeting inpatient criteria, or a day of that stay it regards as unnecessary, is a deduction the hospital argues about after the patient has gone home and the cost has been incurred. Reviewing at admission and at defined points during the stay moves that conversation to the moment when documentation can still be completed and the level of care can still be justified or changed.

The utilisation management metrics that make it manageable are the share of admissions reviewed against criteria, the avoidable-day rate with a recorded reason — awaiting an investigation, awaiting a consult, awaiting a discharge decision, social reasons — and the proportion of denials attributable to medical necessity rather than to documentation or process failures. That last split is the useful one, because the two causes have entirely different remedies: a genuine necessity dispute is a clinical and contractual matter, while a documentation failure is a workflow defect the hospital can fix on its own. Utilisation review sits close to denial management and to discharge planning, and shares the same underlying dependency on the record being complete while the patient is still admitted.

Working through a shortlist?

Our FAQ answers the practical questions that follow the vocabulary — modules, security and compliance, onboarding, and pricing. A live demo covers the rest.