Amit Bajpai and Mithun Vakharia Bring Four Dimensions to Hospital Data Audits
At HealthDataCon 2026, Amit Bajpai and Mithun Vakharia outlined a practical approach to auditing hospital data, showing why connected systems and high pass rates still require closer examination before AI adoption.
The interfaces are green, the new electronic medical record is live, and the implementation team has celebrated. Amit Bajpai asked HealthDataCon 2026 participants to consider what happens next: “Is your data healthy?”
Speaking during the conference’s Europe, Middle East and Africa program, Bajpai, a program manager, joined Mithun Vakharia, co-founder of Santeware Healthcare Solutions, to outline a repeatable approach to auditing hospital data. Their session, “Audit Your Data Like You Audit Your Processes,” drew on their experience with migrations and integration to examine what successful connectivity can leave unresolved.
Their proposed four-dimension method connects a management question—whether leaders can trust their information—to specific records, validation rules and corrective actions. Vakharia described the automated assessment as a work in progress and used synthetic data to demonstrate it.

Separate connectivity from trustworthy data
Bajpai described familiar problems: one patient represented by multiple spellings, years of clinical history stranded in an archive, and departments producing incompatible answers to the same performance question. In multilingual settings, differences between Arabic and English representations of names can complicate patient matching.
The consequences extend beyond reporting. A missing allergy can affect a clinical decision; an incorrect billing field can delay a claim. A migration that transfers demographics while leaving clinical history behind may preserve an expensive dependency on the old system.
The federal SAFER guide reinforces the patient-identification concern. It addresses duplicate and commingled records and emphasizes that reliable identification requires staff training and dependable procedures alongside technology.
Bajpai compared integration infrastructure to a road: it enables transport, while the contents still require inspection. Their framework separates accessibility, trustworthiness and usability. Extracting records addresses the first; normalization and governance support the second; dependable analytics and other downstream uses depend on both.
One example made that distinction tangible. A mandatory email field populated with a dummy address satisfies a basic presence check but still prevents the hospital from reaching its patient.
Begin with one pathway and four dimensions
The speakers offered a starting point that does not depend on buying software. Select one important pathway, such as admission or appointment booking, and examine a manageable sample of recent records. Count missing or misused required fields, incomplete or incorrect entries, and duplicate records. Check coding and exchange requirements, rank the five most important problems, assign owners and repeat the assessment.
Vakharia then organized the larger assessment into four dimensions.
Workflow and process examines whether records reflect the patient journey. Illustrative checks included orders without results, encounters without discharge information and duplicate registrations.
Data entry and completeness examines whether required information is present and properly entered, including missing fields and orphaned records.
FHIR conformance and data integrity examines structure and relationships: required elements, data types, references between resources and broken links.
Terminology and value sets examines whether codes match the applicable requirements, including ICD-10, SNOMED CT, LOINC and mappings from local codes.
Those standards serve different purposes. LOINC, for example, identifies observations and measurements; its documentation explains that local identifiers can coexist with standard codes through dual coding. The practical task is preserving meaning when information travels.
The wider field already offers examples of systematic assessment. OHDSI’s dashboard runs checks against the OMOP Common Data Model using configurable thresholds and transparent results. It provides useful context for the presenters’ emphasis on repeatability, although it does not validate their proposed scoring method.
Look beneath the overall score
The demonstration’s most revealing result was the gap between a raw pass rate and an overall score.
Using a fictional hospital and synthetic records, Vakharia showed an assessment covering 573 records and 23,945 data points. Of those points, 23,389 passed, producing a 97.7% pass rate. Yet the proposed data foundation score was 82 out of 100.
The difference came from the model’s four equally weighted dimensions. Displayed scores were 99 for workflow and process, 80 for integrity and relationships, 97 for entry and completeness, and 51 for terminology and standardization. Giving each dimension 25% weight prevented the large volume of passing checks from overwhelming the weak terminology result.
These were demonstration figures, not findings from a hospital evaluation. The presentation did not establish that a particular score predicts clinical safety, financial returns or readiness for an AI application.
An audience question pressed the remaining issue: could an overall score still hide a critical weakness? Vakharia said weights and rules could be adapted to organizational priorities. Bajpai added that a revenue-cycle application and a clinical application may require different emphasis.
The practical implication is to retain the individual results and define which failures require action regardless of the average. Changes to weights or rules also need documentation; otherwise, a higher score may reflect a changed assessment rather than better data.
Validate the rules as carefully as the records
An assessment is only useful when its definition of failure fits the intended use.
HL7’s guidance describes validation of structures, code bindings, profiles and other computable requirements. It also explains that automated methods are incomplete and that additional business rules and human inspection remain necessary.
The demonstration’s administrative-gender example illustrates why rule design matters. The FHIR R4 value set explicitly includes “unknown,” alongside “male,” “female” and “other.” An explicit unknown value therefore cannot automatically be treated as a base-standard violation. A local requirement may call for additional information, but that is a separate question from whether the code is valid.
The same reasoning applies to workflow checks. An order awaiting a result and an order whose result has been lost require different responses. An encounter still in progress should be assessed differently from a completed admission missing discharge information. Status, timing and purpose belong in the rule.
Vakharia’s emphasis on reaching agreement among stakeholders is especially relevant here. Clinical, operational and technical teams need to agree on what each check means, why it matters and who can resolve a failure. Improving completeness should preserve uncertainty accurately rather than encourage staff to enter a convenient placeholder.
Give the board evidence and owners
The speakers proposed two complementary outputs: record-level evidence for teams doing the repair, and a concise executive report showing risks, priorities and progress.
The detailed view would connect a failed check to affected records, explain the reason and identify possible corrective steps. The management view would translate findings into patient-safety, revenue, clinical-integrity and interoperability concerns. Bajpai also emphasized the human factor: recurring entry problems may reveal a need for training or workflow redesign.
For the proposed automated assessment, Vakharia described extracting a defined historical dataset and running analysis within the hospital’s perimeter. That is their proposed deployment arrangement. It should be distinguished from a blanket legal requirement: HHS guidance permits cloud storage outside the United States under HIPAA when the required agreement and other applicable safeguards are in place. Requirements for a particular deployment still depend on its jurisdiction and circumstances.
Their suggested 60-to-90-day assessment window also came with conditions. In the discussion, Bajpai identified infrastructure and integration readiness as potential delays. Vakharia highlighted access to historical data and the time needed to agree on validation rules.
Those dependencies belong in the plan alongside the scan itself. The next review needs evidence that source records or processes changed, named responsibility for unresolved problems, and a comparable reassessment.
The speakers’ closing exercise offered a concrete place to begin: choose one clinical question, trace the information needed to answer it across the hospital’s systems, and inspect the gaps encountered along the way.