National Accreditation Board for Hospitals & Healthcare Providers (NABH)‘s Digital Health Standard for Hospitals — one of several digital-health programmes NABH runs, distinct from its separate standards for HIS/EMR vendors and other services — has eight chapters.
Digital Operations Management (DOM) covers 6 standards and 25 of the 182 Objective Elements. Six of those 25 are Core — the most of any chapter, ahead of AAC and FPM at 3 each.
Read the standard yourself. NABH’s Digital Health Standard for Hospitals is available in full, free, at nabh.co/digital-health-standards — creating a free NABH account is required to access it. Nothing in this piece substitutes for the source document itself.
NABH digital operations management here means something specific: IT policy, IT support and maintenance, IT/digital asset management, disaster recovery, access control, and facility maintenance tracking — the operational discipline that sits behind a hospital’s clinical systems.
Recommended starting point: This piece is from a series on the NABH Digital Health Standard for Hospitals and assumes familiarity with many fundamental terms such as Chapters, Standards, Objective Elements, the four bands, and tier requirements. If these terms are new to you, it may make more sense to start from the beginning.
A note on ordering: within each standard below, Objective Elements are grouped by band — Core first, then Commitment, then Achievement, then Excellence — rather than listed alphabetically by letter. This makes each standard’s actual weight easier to read at a glance, but it does mean the lettering runs out of sequence in places. The letter itself is unchanged from the standard; only the reading order is regrouped.
DOM.1 — Written Guidance for IT Resource Usage and Operations
DOM.1 requires the hospital to use written guidance for the usage and operations of IT resources, across 2 Objective Elements — both Core, making DOM.1 the only standard in the entire chapter with no non-Core elements at all.
Core
- DOM.1.a. An IT policy to manage the hospital’s digital operations — covering, per NABH, areas such as IT security, open-source software use, data management, IT access, disaster recovery, monitoring strategy, and change management.
- DOM.1.b. Periodic review of the IT policy — kept current as technology, threats, and regulatory requirements evolve, rather than left untouched after its first version.
Commitment
None under DOM.1.
Achievement
None under DOM.1.
Excellence
None under DOM.1.
DOM.2 — IT Support to Run Digital Operations Smoothly
DOM.2 requires the hospital to use IT support to manage its infrastructure so digital operations run smoothly, across 6 Objective Elements — the largest standard in the chapter.
Core
- DOM.2.d. Continuous support, including software updates and upgrades, for clinical healthcare applications — patching and upgrading treated as an ongoing IT function, not something that happens only when a system breaks.
Commitment
- DOM.2.e. Continuous support, including updates and upgrades, for non-clinical systems — the same discipline extended to administrative and back-office applications.
Achievement
- DOM.2.a. A digital system to manage the internal maintenance plan for IT systems and services.
- DOM.2.c. A digital system to monitor the performance of different healthcare applications.
Excellence
- DOM.2.b. A digital system that generates reports measuring IT infrastructure efficiency.
- DOM.2.f. A formal change request process to manage IT-related changes — changes routed through a defined process rather than made ad hoc.
DOM.3 — Digital System to Manage IT/Digital Assets
DOM.3 requires the hospital to use a digital system to manage IT/digital assets, across 5 Objective Elements.
Core
None under DOM.3.
Commitment
None under DOM.3.
Achievement
- DOM.3.a. A digital inventory record of all IT assets.
- DOM.3.c. A digital system to record and track IT security incidents, issues, changes, and problems.
- DOM.3.e. A digital system to maintain and track records for electronic waste.
Excellence
- DOM.3.b. A centralised digital data repository for all electronic health records (EHRs) — one system of record, rather than records fragmented across departmental silos.
- DOM.3.d. Periodic internal IT audits confirming no major vulnerabilities — a hospital checking its own infrastructure on a schedule, not only after an incident forces the question.
DOM.4 — Disaster Recovery and Service Continuity Plan
DOM.4 requires the hospital to have a disaster recovery and service continuity plan for its digital systems, across 3 Objective Elements.
Core
- DOM.4.c. A digital system to archive and retrieve data — the practical mechanism that makes a disaster recovery plan real, rather than a document describing an intention.
Commitment
- DOM.4.a. A disaster recovery plan to manage patient healthcare records in unforeseen circumstances.
- DOM.4.b. A disaster recovery plan to manage administrative applications in unforeseen circumstances.
Achievement
None under DOM.4.
Excellence
None under DOM.4.
DOM.5 — Access Control to Secure the Digital System
DOM.5 requires the hospital to use access control to secure its digital system, across 5 Objective Elements.
Core
- DOM.5.a. A digital system to manage end-user credentials and authentication — individually assigned, trackable logins rather than shared or generic accounts.
- DOM.5.c. A digital mechanism to protect and restrict data transfer on external storage devices — controlling what can leave the hospital’s systems on a USB drive or similar, not just what comes in.
Commitment
- DOM.5.e. Auto-termination of an electronic session after a predetermined period of inactivity — a logged-in session that doesn’t stay open indefinitely on an unattended workstation or laptop.
Achievement
None under DOM.5.
Excellence
- DOM.5.b. Two-factor authentication across all IT systems.
- DOM.5.d. Official email IDs required for all official communications, as governed by the hospital’s IT policy — rather than staff defaulting to personal email for hospital business.
DOM.6 — Digital System to Track Facility Incidents and Maintenance Events
DOM.6 requires the hospital to use a digital system to maintain and track all incidents and maintenance events of the facility, across 4 Objective Elements.
Core
None under DOM.6.
Commitment
None under DOM.6.
Achievement
- DOM.6.a. A digital record of periodic calibration and maintenance plans for all equipment.
- DOM.6.b. A digital mechanism to notify the maintenance in-charge or Bio-Medical department of scheduled maintenance activities.
- DOM.6.c. A digital record of the collection and disposal of bio-medical waste.
Excellence
- DOM.6.d. The hospital is registered in the Healthcare Facility Registry (HFR) under ABDM.
DOM at a Glance — Every Standard, By the Numbers
| Standard | TL;DR | Core | Commitment | Achievement | Excellence | Total |
|---|---|---|---|---|---|---|
| DOM.1 | Written IT policy, reviewed periodically | 2 | 0 | 0 | 0 | 2 |
| DOM.2 | IT support, maintenance, monitoring, and change management | 1 | 1 | 2 | 2 | 6 |
| DOM.3 | IT/digital asset inventory, incident tracking, EHR repository, audits | 0 | 0 | 3 | 2 | 5 |
| DOM.4 | Disaster recovery and data archival | 1 | 2 | 0 | 0 | 3 |
| DOM.5 | Access control, authentication, external device restrictions | 2 | 1 | 0 | 2 | 5 |
| DOM.6 | Facility maintenance tracking and bio-medical waste records | 0 | 0 | 3 | 1 | 4 |
| DOM total | 6 standards, 25 Objective Elements | 6 | 4 | 8 | 7 | 25 |
The Self-Check
An internal audit exercise an owner can run this week, without an IT background:
- Does the hospital have a written IT policy that’s actually been reviewed in the past year (DOM.1.a/b), or is it a document from years ago nobody has revisited?
- Are clinical application updates and patches applied on a defined schedule (DOM.2.d, Core), or does IT only step in once something has already broken?
- Is there a disaster recovery plan for patient records that’s been tested, with a real archive-and-retrieve system behind it (DOM.4.a/c), or does “backup” mean an external hard drive in someone’s drawer?
- Are user credentials individually assigned and revoked the day someone leaves (DOM.5.a/c), or do departed employees’ logins quietly stay active?
- When was the last time IT assets, security incidents, and facility maintenance were tracked in an actual system (DOM.3.a/c, DOM.6.b) — rather than a WhatsApp group or a notebook at the reception desk?
A hospital finding a “paper or WhatsApp” answer to more than one or two of these has more work in DOM than its digitised OPD or pharmacy systems would suggest.
Why DOM Can’t Be Deferred the Way Some Chapters Can
DOM carries 6 Core Objective Elements — the most of any chapter in the entire standard, ahead of AAC and FPM at 3 each, and far ahead of chapters like COP and HRM, which have none. That Core load is also spread across four separate standards (DOM.1, DOM.2, DOM.4, DOM.5) rather than concentrated in one, the way MOM’s two Core elements sit entirely inside MOM.4. A hospital can’t clear DOM’s Core floor with one fix — it has to get its written IT policy, clinical-application patching, disaster recovery archival, and access-control basics right simultaneously.
This is also where operational discipline becomes visible and auditable for the first time in the standard. DOM.3.c and DOM.3.d specifically require tracking IT incidents and running periodic internal audits — meaning a hospital’s actual operational discipline, not just its stated intentions, gets tested here. A hospital that has digitised its clinical front end but still manages IT assets, incidents, and access through paper logs or a WhatsApp group has built impressive-looking digitisation on an undisciplined operational base.
Contrast this with a chapter like HRM, which has zero Core elements and can genuinely be sequenced later in a hospital’s roadmap. DOM does not offer that flexibility — its Core elements are as non-negotiable at Silver as anything in AAC or MOM.
This is the same reason operational excellence for Indian hospitals depends on getting the unglamorous operational layer right, not just the visible clinical one — the same instinct behind understanding why a system works at a structural level rather than just clearing the nearest bar.
FAQ
How many Objective Elements does the DOM chapter have in NABH’s Digital Health Standard for Hospitals?
25 — across 6 standards, out of 182 total across the standard.
What are DOM’s Core (mandatory) Objective Elements?
Six, the most of any chapter: a written IT policy and its periodic review (DOM.1.a, DOM.1.b); continuous support for clinical applications (DOM.2.d); a digital archive-and-retrieve system (DOM.4.c); and digital end-user credential management plus restricted external-device data transfer (DOM.5.a, DOM.5.c).
What does NABH’s DOM chapter require for disaster recovery?
DOM.4 requires disaster recovery plans covering both patient healthcare records (DOM.4.a) and administrative applications (DOM.4.b), backed by a digital system that can actually archive and retrieve the data (DOM.4.c, Core).
Is DOM about clinical workflows or IT operations?
IT operations specifically — hospital workflow digitisation NABH scores under DOM covers IT policy, support, asset management, disaster recovery, access control, and facility maintenance tracking, not clinical documentation (that’s AAC, COP, and MOM).
The Decision
The question DOM actually asks isn’t whether a hospital has digitised its clinical front end — that’s what the other chapters test. It’s whether the operational discipline behind that digitisation is real: a written and reviewed IT policy, patches applied on schedule, a disaster recovery plan that’s actually been archived and could actually be retrieved, and access controls that don’t quietly leave former employees logged in. DOM has more mandatory ground to cover than any other chapter, and none of it can be deferred to a later phase.
Leave a Reply