“Digitisation” sounds like a purchase decision — pick a HMIS, sign the contract, go live. But a large share of what NABH’s Digital Health Standard actually scores has nothing to do with software capability. Meeting NABH digital health documentation requirements is, for many Core and Commitment elements, a documentation-discipline problem: does a policy exist, is it approved, is it current, and is anyone actually following it.
A hospital can own excellent software and still fail these elements. A hospital with modest software can pass them, if its paperwork is in order.
This piece is the governance groundwork the Vendor-Dependency Map piece pointed back to: before trusting any vendor’s answer to “which of these elements does our system already support,” a hospital needs its own documentation architecture in a state where that question can even be answered honestly.
Read the standard yourself. NABH’s Digital Health Standard for Hospitals is available in full, for free, at nabh.co/digital-health-standards — creating a free NABH account is required to access it. The documentation framework below is described in the standard’s own introductory guidance (2nd Edition, September 2025, pp. 17–21), ahead of the eight chapters this series has covered individually; see the series hub for the full chapter list.
A hospital that starts its NABH digital readiness work with a technology purchase, before auditing whether its existing SOPs meet this bar, is very often solving the wrong problem first.
NABH’s Documentation Pyramid
| Level | What It Covers | Example |
|---|---|---|
| 1. Policy Documents | Mission statement, vision statement, strategic plans, policies that transcend time and guide decisions as the operational, legal, and technological environment changes | A hospital’s data-privacy policy, or its policy on digital documentation standards |
| 2. System Documentation (SOPs) | Standard Operating Procedures connecting the policy layer to day-to-day action — operational and quality-system procedures for specific departments or activities | The SOP for entering a discharge summary into the HIMS |
| 3. Work Instructions | Step-by-step instructions for executing a task, including the physical steps involved | The exact keystrokes/screens a nurse follows to log a structured care-plan entry |
| 4. Forms, Formats, Records | The forms and formats used to capture information, and the filled-in records that result — physical or electronic | The digital nursing-notes template itself, and each completed patient entry |
| 5. Documents of External Origin | Licenses, statutory clearances, legal contracts, MoUs — not alterable by the hospital | A vendor’s data-processing agreement, or a state license for a digital pharmacy module |
The standard is explicit that most organizations add this fifth, externally-sourced layer on top of the original four; either way, the direction of the pyramid matters more than the exact count of levels. Policy sits at the top because it changes rarely and everything below it should trace back to it. Records sit near the bottom because they are generated constantly and document that the levels above are actually being followed — not just written down.
What Makes a Document “Controlled”
NABH doesn’t score whether a document exists in the abstract — it scores whether it’s a controlled document, meaning it carries a defined identity that prevents unauthorized or undocumented changes. Per the standard’s own characteristics list, a controlled document has:
- A name
- A defined purpose
- A date of creation
- A date of approval
- A date of review (and, optionally, a date of expiry)
- A named signatory for creation
- A named signatory for approval
- A named signatory for alterations (which may or may not be the same person as the creator)
- Numbered pages, and often a document number
Most hospitals keep this identity information in a “control box” — a small header or footer block on the document itself, showing organization name, document code, issue date, and next revision date, alongside signature lines for who authorized and issued it. It’s a small piece of formatting. It’s also, in NABH’s own document-control logic, the difference between a policy that exists and a policy that counts.
This is the hospital SOP NABH digital assessors actually want to see: not a well-written procedure sitting in someone’s inbox, but one with a name, an owner, an approval date, and a review cycle that’s actually been followed — because an SOP without those characteristics isn’t a controlled document under the standard, no matter how accurate its content is.
Where Hospitals Actually Fail This
The common failure pattern isn’t a missing policy — it’s an informal one. A hospital’s OPD digital-registration process might be followed correctly and consistently by staff, but exist nowhere as a named, dated, approved SOP; it’s tribal knowledge, taught person to person, with no control box and no review date. When an assessor asks to see the controlled document behind the process, there isn’t one to show — even though the process itself works fine day to day.
This gap tends to surface after, not before, a hospital has already bought a HMIS or EMR upgrade specifically to chase NABH digital readiness. The software goes live, staff adopt it well enough to use daily, and the hospital still doesn’t clear the relevant Core or Commitment elements — because what was missing was never the system’s capability. It was a named, approved, version-controlled SOP describing how the system is supposed to be used, sitting above the software rather than inside it. Buying the system solved a problem NABH wasn’t actually scoring, and left the real gap untouched.
The Self-Check: Audit Before You Buy
Before any HMIS/EMR purchase decision made in the name of NABH digital readiness, an owner should be able to answer:
- For the processes we already run digitally — registration, prescriptions, nursing notes — does a named, approved SOP exist for each one, or is the process just “how we’ve always done it”? If the answer is the latter, no software purchase closes this gap; only writing the document does.
- Do our existing policies and SOPs carry the full control-box identity — name, purpose, creation date, approval date, review date, signatories? A procedure without these is not a controlled document under the standard, regardless of how good the procedure itself is.
- Is there a NABH policy manual digital health reviewers can actually open and trace — from mission and policy, down through SOPs, down to the forms and records staff fill in daily — or does that trail break somewhere in the middle? A broken trail is usually the real finding an assessor writes up, not a technology gap.
- Has anyone reviewed these documents on the schedule the documents themselves specify? A policy with a review date that passed unreviewed a year ago is a documentation-discipline finding waiting to happen, independent of any system purchase.
FAQ
Does NABH digital health accreditation require buying document-management software?
No. NABH digital health documentation requirements are about content and control — named, dated, approved, version-tracked documents — not about which platform stores them. A hospital can meet this bar with well-organized physical or shared-drive documents, provided the control characteristics are genuinely present.
What’s the difference between a policy, an SOP, and a work instruction?
A policy is a standing principle that changes rarely (e.g., a data-privacy stance). An SOP describes the steps for a process end to end (e.g., how a discharge summary gets entered and approved). A work instruction is more granular still — the exact physical steps for one part of that process. Most hospitals have work instructions embedded inside SOPs rather than as separate documents, which is acceptable as long as the control characteristics are present at the SOP level.
What does a hospital SOP NABH digital assessors will actually accept look like, versus one that fails?
The content can be identical. What differs is the control-box identity: a name, a defined purpose, creation and approval dates, a review date, and named signatories. An SOP that’s accurate but undated and unsigned is functionally a draft, not a controlled document, in NABH’s own terms.
Should documentation work happen before or alongside a technology purchase?
Before, wherever possible — a hospital that audits its documentation architecture first knows exactly which technology gaps are real, versus which “gaps” a proper SOP would have closed for free. This is also the groundwork that makes the due-diligence question raised in the Vendor-Dependency Map piece answerable in the first place.
The Decision
The question isn’t whether a hospital eventually needs some technology investment for NABH digital readiness — for at least a few chapters, it does. It’s whether that investment gets decided after the hospital already knows which of its gaps are documentation gaps, or before, when an undocumented process gets misread as a missing system.
Leave a Reply