Why nobody trusts the number
Data quality and governance failures in hospital reporting almost never announce themselves as data problems. They announce themselves as a meeting where the medical director says the OPD figure cannot be right because his department saw more patients than that, the analytics team defends the extract, and the discussion ends without a decision. The number was probably correct under its definition; what was missing was a shared understanding of what it counted.
Three distinct failures produce this scene. The definition was never written down, so two people counted different things. The capture was poor, so the underlying records were incomplete before anyone queried them. Or the lineage was opaque, so nobody in the room could establish where the figure came from. Each requires a different fix, and treating all three as a reporting problem — the usual reflex — solves none of them.
Governance is the machinery that prevents all three. It is unglamorous work: writing definitions, naming owners, setting validation rules, and reviewing a scorecard. Hospitals that skip it spend the equivalent effort every month arguing about numbers, with the difference that the arguing produces nothing durable.
The dimensions of data quality, made specific
Quality is not one property, and naming its dimensions separately is what makes it measurable. Completeness asks whether required fields are populated — what proportion of admissions have a recorded discharge diagnosis. Accuracy asks whether the recorded value matches reality, which usually requires sampling against a source of truth. Timeliness asks whether the record existed when it was needed, not merely whether it exists now.
Consistency asks whether the same fact agrees across systems: does the patient's date of birth in registration match the one in the lab system. Validity asks whether values fall within permitted ranges and code sets — a systolic pressure of 900, a discharge date before the admission date, a diagnosis code that is not in the ICD-11 set in use. Uniqueness asks whether one real-world entity has exactly one record, which in a hospital is dominated by the duplicate patient problem.
Each dimension maps to a different control. Completeness is fixed with mandatory fields and workflow gates; validity with range checks and controlled vocabularies; uniqueness with deduplication at registration and a strong patient matching rule; timeliness with escalation on overdue documentation. Diagnosing which dimension is failing tells you which control is missing.
Six dimensions and the control that addresses each
- Completeness — mandatory fields and workflow gates at capture
- Validity — range checks and controlled code sets
- Consistency — single source of truth per attribute, propagated not retyped
- Timeliness — overdue documentation escalation with a named owner
- Uniqueness — deduplication and patient matching at registration
- Accuracy — periodic sampled verification against the clinical record
One metric, one definition: building the data dictionary
A data dictionary is the enforceable statement of what each metric means. For every metric it should record the plain-language definition, the exact numerator and denominator, the inclusion and exclusion rules, the source fields, the calculation cadence, the owner, and the version history. Occupancy is the canonical example: midnight census or average daily census, against sanctioned beds or operational beds, including or excluding day-care and observation.
The dictionary only works if it is the single place the definition lives, which means the reporting layer must implement it rather than paraphrase it. Where a metric is coded independently in a dashboard, a monthly spreadsheet, and an accreditation return, three definitions will drift apart within a year regardless of what the dictionary says. Expressing metrics once in a semantic layer that all reporting consumes is the structural fix.
Version definitions and date the changes. When occupancy is redefined to exclude day-care, the historical series changes, and anyone comparing this year to last needs to know that. A dictionary entry that shows definition v2 effective from April, with a note on the impact on the trend, prevents a year of quiet misinterpretation.
Ownership and stewardship that name individuals
Governance fails when responsibility is assigned to departments rather than people. The workable model has three named roles per data domain. A data owner is a senior person accountable for the domain — typically the head of the function that generates it, so the medical records officer owns clinical coding data and the finance controller owns billing data. They decide definitions and arbitrate disputes.
A data steward is the operational person who monitors quality day to day, investigates exceptions, and chases correction at source. This is the role that actually determines whether governance functions, and it needs allocated time rather than being added to a full job. A technical custodian maintains the pipelines, access controls, and lineage documentation, and implements what the owner decides.
Convene these people as a small governance group on a monthly cadence with a fixed agenda: scorecard review, open data issues, definition change requests, and access reviews. Keep it small enough to make decisions. A twenty-person data governance committee will produce minutes; a five-person one will produce rulings.
Validate at capture, not at reporting
Every correction made at the reporting layer is a permanent tax. The underlying record stays wrong, the fix has to be reapplied every cycle, and the operational system continues to make decisions on bad data — a wrong allergy or a wrong payer category harms the patient long before it distorts a report. The only durable fix is at the point of capture.
Capture-time controls are ordered by strength. Making a field structurally impossible to get wrong is best: a dropdown of valid wards rather than free text, a date picker that cannot precede the admission date, an ABHA number field that validates its own format. Next is a hard block that prevents progression until a required field is complete. Weakest is a soft warning, which experienced users learn to dismiss without reading.
Apply the strongest control only where the field genuinely matters, because mandatory fields have a cost. A registration form with thirty required fields produces junk entries — a single dot in the address, a placeholder phone number — and makes the data worse while appearing to make it better. Make five fields genuinely mandatory and enforce them properly rather than thirty nominally.
Capture controls in order of strength
- Structural: controlled lists, pickers, derived values that cannot be mistyped
- Hard block: cannot proceed until the field is valid
- Cross-field rule: discharge date must follow admission date
- Duplicate detection at registration before a new record is created
- Soft warning: useful for judgement calls, ignored for everything else
A data-quality scorecard people actually read
The scorecard turns quality from an opinion into a tracked metric. Pick eight to twelve checks that matter operationally, express each as a percentage with a target, and report them monthly by department and branch. Discharge summaries completed within twenty-four hours; admissions with a coded principal diagnosis; patients with a validated contact number; lab results with a recorded authorisation time; duplicate patient records created this month.
Show the trend and the owner beside each check, and route exceptions back to the source department rather than to the analytics team. The steward's job is to make the exception visible to the person who can fix it, not to fix it themselves — a steward who corrects records is a steward who has become a permanent workaround for a broken process.
Platforms that expose completeness and timeliness in the operational workflow help here, because a HealUDoc-style view of pending documentation lets a ward sister see her own outstanding items today rather than reading about them in a report next month. The scorecard then measures a problem the department can already see, which is what makes the target credible rather than punitive.
Governance under DPDP and accreditation scrutiny
Data governance and data protection are increasingly the same programme. The DPDP Act 2023 requires that personal data be accurate and that processing be purposeful and limited, which are data quality obligations as much as privacy ones. An inaccurate patient record is both a care risk and a compliance exposure, and the same stewardship machinery addresses both.
Practically, extend the governance group's remit to cover access reviews, retention decisions, and the record of which systems hold which categories of personal data. Knowing where identifiable data lives is a prerequisite for both a breach response and a routine access review, and most hospitals discover on first attempt that the answer includes several spreadsheets nobody had catalogued.
NABH assessment pulls in the same direction. Assessors ask how an indicator was calculated, who verified it, and how errors are detected and corrected — which is a request for the dictionary, the steward, and the scorecard. A hospital that runs governance for its own operational benefit finds accreditation evidence largely produced as a by-product, rather than assembled in the fortnight before an assessment.
“We used to spend the first twenty minutes of every review meeting arguing about whose number was right. Writing one definition per metric and putting a name against it gave us those twenty minutes back, every month.”
