There is a difference between a system that is compliant and a system that is auditable, and most healthcare software in India is the first without being the second.
Compliant means the rules were followed. Auditable means you can prove it, months later, to somebody hostile, from a record that could not have been edited after the fact. A clinic can be scrupulously compliant and completely unable to demonstrate it — which, when an inspector is sitting across the table, is the same position as not having been.
The warning dialog is not a control
Here is the pattern almost every clinical system uses. A statute prohibits something. The software shows a message: “This action may violate Section 24(b). Continue?” There is an OK button.
That is not a control. It is a record that somebody was told, and it fails in three ways at once.
It fails at 7pm on a Friday, when a tired person clicks through. It fails because it produces no durable evidence — the dialog was shown, dismissed, and left nothing behind. And it fails on the only occasion that counts: the audit, where the question is not “was the user warned” but “did the prohibited thing happen”, and the honest answer is that the database would have accepted it either way.
The alternative is unfashionable and simple. If the statute says a thing must not happen, the database must not be able to store it. A constraint, a trigger, a foreign key that has no valid target — whatever form it takes, the property required is that a prohibited state cannot be written, by any code path, including the one somebody adds next year in a hurry.
We built an ART Act platform for Indian fertility centres on exactly this principle: twenty-one provisions of the ART Act 2021 and Rules 2022 enforced as database constraints rather than interface warnings. An embryo transfer that would breach a statutory limit does not produce a dialog. It fails, and the attempt is recorded.
Four properties an auditable clinical record needs
1. Append-only
Clinical and regulatory records are not editable rows. A correction is a new entry that supersedes an old one, and both survive. The instinct to UPDATE is strong because it is how most software is built — and it is precisely the property that makes a record indefensible, because an inspector cannot distinguish a record that was always right from one that was made right last week.
2. Chained, not merely timestamped
A timestamp proves when a row says it was written. It does not prove the row has not been altered since, or that a row was not removed from the middle of a sequence. Chaining each entry to its predecessor makes a silent deletion detectable: the chain no longer verifies, and you can say which link broke.
This is not blockchain theatre. It is a hash column and a verification job, and it converts “we believe the record is intact” into “here is the check that says so.”
3. Consent as a first-class object with a lifetime
Consent is not a checkbox and not a scanned PDF in a folder. It is a record with a scope, a date, a version of the document consented to, the identity of who witnessed it, and — the part most systems omit — a withdrawal path.
The question that decides whether your consent model is real: if a patient withdraws consent today, what exactly happens, and which downstream actions become prohibited from this moment? If the answer is “we’d make a note”, the consent register is documentation, not a control.
4. Custody, unbroken
For anything physical — specimens, samples, stored material — the record must answer who held it, from when to when, with no gaps. A custody trail with a hole in it is not a partial record; for evidentiary purposes it is closer to no record, because the hole is exactly where a question will be directed.
Pick a patient episode from nine months ago. Without asking anyone, produce: every consent in force at each step and its version; who performed each procedure and under what authorisation; the custody trail of any stored material; and every change made to that record since, with who made it and what it said before.
Time the exercise. If it takes more than an hour, or if any part of it depends on a person’s memory or a paper file in a cupboard, the system is a record-keeping aid rather than a record.
Why bolting it on afterwards does not work
The usual sequence is: build the clinical workflow, get it working, add compliance before the inspection. It is the natural order and it does not produce an auditable system, for a reason that is structural rather than a matter of effort.
By the time compliance is added, the database is full of rows that would violate the new constraints. You cannot switch on a rule that your existing data breaks. So the rule gets added at the application layer instead, applying only to new records, and the system now has two classes of data — the constrained and the historical — with no marker distinguishing them. Every query afterwards has to know which is which, and most will not.
The same applies to append-only. Retrofitting it onto a table that has been updated in place cannot recover the history that was overwritten. That information is gone, and no amount of later rigour brings it back.
This is the honest case for spending the first weeks of a clinical build on the data model, before anybody sees a screen: the constraints are cheap to impose on an empty database and impossible to impose on a full one.
What this buys beyond the inspection
Compliance work is usually justified defensively, which undersells it. A record with these properties is also the thing that settles disputes, because the answer to “what actually happened” exists and cannot be argued with. It makes handovers between clinicians safe, because the record is complete rather than summarised. And it makes a clinic saleable, because diligence is a query rather than a quarter.
The DPDP Act adds a further edge worth naming: consent, retention and erasure obligations, with penalties up to ₹250 crore. Erasure in particular is a schema question long before it is a policy question. If personal data is scattered across denormalised copies and export files, honouring an erasure request is an archaeology project. If it has one home and everything else references it, erasure is a transaction.
None of this is about being more careful. Careful people already work in these clinics; that has never been the constraint. It is about building the system so that the careful thing is the only thing it can do — and so that on the day somebody asks you to prove it, the proof is a query and not a search.