India's EHR Standards on audit trails: log every view, never overwrite, detect edits

The short answer

Picture a patient asking who has looked at their records this year. Under India’s EHR Standards, the system should be able to answer, because viewing counts as an action to log, not only editing. The same standards ask that old versions are kept and that changes to records or logs can be detected.

India’s Electronic Health Record Standards, published by the National Resource Centre for EHR Standards (NRCeS), say all actions on electronic health information, “including viewing”, should be recorded¹, each with the date, time, record id and user id¹; that data once entered must become immutable, with revisions saved as new versions¹; and that any alteration or deletion of health information or of the audit logs must be detected.¹ They list ISO 27789 as the advisory standard for audit trails.¹

Many hospital systems log edits but not views, keep logs any administrator can change, or overwrite a field on update. Each of those is a gap against this text.

Where the standards come from

The health ministry notified EHR standards for India in September 2013 and later had an expert group revise them; NRCeS publishes the current set.¹ They are a recommended technical baseline rather than a statute, but other frameworks lean on them, and NABH’s digital health standards for hospitals include an element for a digital system that “captures the audit trails of each transaction”.³

Records are appended, never overwritten

The “Principles of Data Change” section is stricter than most software defaults. Data entered in a health record system must become immutable. No update command should be available to users or administrators to change a stored record. A revision creates a new record, marked ACTIVE, and earlier versions are marked INACTIVE.¹

In practice that means three things for builders:

• An UPDATE that changes a diagnosis in place is out of line with the standard; inserting a new version is in line.
• The old version stays readable, so “what did the chart say on Tuesday?” has an answer.
• The audit trail ties each version to who created it.

If your system speaks FHIR, the version history (_history, vread) is the natural fit; our post on FHIR versioning explains how it works and where servers differ.

What each log entry holds

The standards ask that actions be recorded with the date, time, record identification and user identification whenever health information is created, modified (non-clinical data only), deleted (stale and non-clinical data only) or printed, with an indication of the action.¹ ISO 27789 says the same minimum in its own terms: identify the user, the subject of care, the function performed, and the date and time.²

A field-by-field template that covers both:

The standards also say all or a chosen set of recorded audit information must be displayable or printable for review, on request or at a set period.¹ A log nobody can read back in a usable form doesn’t meet that.

Viewing counts

This is the line most systems miss. Edit logs are common; view logs are not, because views are frequent and logging them costs storage. But privacy incidents in hospitals are usually about viewing: a staff member opening a celebrity’s chart, or a relative’s. The standard’s phrase “including viewing”¹ is there for that reason.

Practical tips: log views at the record level, not every screen redraw; keep view logs in a separate store sized for volume; and review a sample regularly, since a log nobody reads deters little.

Detect changes to the log itself

The integrity section asks that all alterations and deletions of health information and of audit logs be detected¹, and recommends SHA-256 or stronger hashing to check that information wasn’t altered in transit.¹

“Detected” is the key word. Access controls reduce who can change a log, but an administrator can usually still do it. Detection needs something an administrator can’t quietly redo, such as entries linked by hashes so a removed or edited line breaks the chain, with the latest hash kept somewhere else. The glossary entry on hash-chained logs explains the idea.

A gap check for your system

AI tools are users too

When an AI scribe drafts a note, or an agent updates a record through an API, it is performing actions on health information. Under the standards’ logic, each one needs a user identification, a timestamp and an action type, and it should create a new version rather than overwrite. Two easy mistakes: running the AI integration under a clinician’s personal login, which hides who acted, or under one shared service account for every tool, which hides which tool acted.

Give each AI tool its own identity, record the clinician on whose behalf it acted, and keep its log entries in the same tamper-evident store as everyone else’s. Our post on what EHR audit logs record covers the research on how these logs are used. For what Deedglass does around AI agent writes in hospitals, see /healthcare; the FHIR write benchmark shows where its checks miss.

To try the checks on synthetic data, open the playground in your browser. To see what an AI agent on your machine can change, run npx deedglass scan (what the grade means) or paste its MCP config into /check; neither uploads your data. Our AI agent permissions report shows what public agent setups commonly leave open.

Written with AI assistance and checked against our claims register.