TRV-2026-1769Version 1 · Certified
Reason for this version
Certified into the record
Canonical text (the exact bytes fingerprinted)
TRUVACE RECORD VERSION record: TRV-2026-1769 version: 1 kind: certified reason: Certified into the record timestamp: 2026-10-18T01:09:56.115759Z status: published lens: g_space sector: health headline: Implementation of Duke Machine Learning Data Quality Assurance Framework in a Pakistani Healthcare Institution dek: PurposeHigh-quality data are critical for developing healthcare machine learning (ML) models yet remain a major challenge in low- and middle-income countries (LMICs). This study evaluated the applicability of the Duke Institute for Health Innovation's (DIHI) Machine Learning Data Quality Assurance (ML-DQA) framework in an LMIC setting using two ML projects at a tertiary care hospital in Pakistan.MethodsWe applied the ML-DQA framework to two ML projects, Sepsis Watch (SW) and In-hospital Mortality Prediction (IMP… gain_title: Applying a structured data quality assurance process at a Pakistani tertiary hospital identified which data elements met quality standards for sepsis and mortality prediction models, informing model development. problem_title: (none) trace_subject: (none) gain_reading: Applying a structured data quality assurance process at a Pakistani tertiary hospital identified which data elements met quality standards for sepsis and mortality prediction models, informing model development. gain_evidence: The Duke ML-DQA framework effectively identified data limitations and informed model development | identifying elements that met quality standards problem_reading: (none) problem_evidence: (none) quick_read: Researchers took a data quality assurance framework developed at the Duke Institute for Health Innovation and tested it at a tertiary care hospital in Pakistan. They ran it on two machine learning projects, one for sepsis monitoring and one for predicting in-hospital mortality, to see whether the data were usable for model building. The work matters because poor data quality is described as a major obstacle to healthcare machine learning in low- and middle-income countries. The abstract reports that the framework was useful in a resource-constrained setting, but it gives no figures on data quality or on how the resulting models performed. limitation: tag: Evidence-backed gain key_points: The framework was applied to two projects: Sepsis Watch and In-hospital Mortality Prediction. | The four phases were pre-DQA, data element pre-processing, ML-DQA checks, and ML-DQA adjudication. | Pre-processing included consolidating differently labelled glucose variables. | Checks assessed plausibility, conformance, and completeness of data elements. | Two independent clinicians reviewed the reports to judge suitability for model development. rundown: In the first phase, the teams consulted clinicians and project members to identify which data elements each model required. This tied the data checks to clinical needs rather than to technical convenience alone. Data were then transformed and harmonized. One example given is the consolidation of glucose variables that had been labelled in different ways, a typical problem when records come from varied sources. Automated checks examined plausibility, conformance, and completeness to find elements that met quality standards. In adjudication, two independent clinicians reviewed the resulting reports and decided whether the data were suitable for developing each model. sources: - peer_reviewed | Health Informatics Journal | https://doi.org/10.1177/14604582261486769 | 2026-10-07 prev: 0000000000000000000000000000000000000000000000000000000000000000
- sha256
- 3c4101739ea68cd82749531def77b8f7308224db0db80d16d133f7f130ea1106
- previous
- 0000000000000000000000000000000000000000000000000000000000000000
Verify this record
How to verify without trusting this page
Fetch the canonical text of any version from /api/record/TRV-2026-1769 and hash it yourself — for example shasum -a 256 on the saved canonical field. The result must equal content_hash, and each version’s text ends with prev:followed by the prior version’s hash (version 1 chains to 64 zeros). If a single character of any version had been altered since certification, the chain would not reproduce.
ace