Clinical AI Data Quality and Data Lineage in Viet Nam: Governing Inputs, Missingness, Coding Changes and Data Pipelines
IMPLEMENTATION INSIGHTS
Clinical AI Data Quality and Data Lineage in Viet Nam: Governing Inputs, Missingness, Coding Changes and Data Pipelines
IMPLEMENTATION INSIGHT
Last reviewed: 3 October 2026
A clinical AI system can remain completely unchanged while the data around it quietly change. A laboratory replaces an analyzer. A field in the electronic medical record begins using a different unit. A diagnosis code is remapped. A software upgrade changes where information is stored. A new interface converts an empty value into zero. A hospital opens a new service and the patient population shifts. A vendor modifies an API. Nothing about the AI model itself has changed, yet the information reaching it is no longer quite the same.
The AI may continue producing outputs without any obvious technical failure. That is what makes data-quality problems particularly difficult in clinical AI. Healthcare organizations often focus on whether a model is accurate, validated and monitored for performance deterioration. Those questions matter, but they sit further down the chain. Before an AI system can interpret clinical information safely, the organization needs reasonable confidence that the information reaching it is complete enough for the intended use, correctly represented, semantically stable, timely and traceable to its source.
This is where data quality and data lineage become patient-safety issues. In this article, data quality means whether data are sufficiently fit for a particular clinical AI use, rather than whether a dataset is universally “clean.” Data lineage means the ability to trace important data from their source through the transformations, mappings, interfaces and systems that eventually deliver them to the AI. The practical governance question is therefore straightforward: Do we understand what data the AI is actually receiving today, where those data came from, what happened to them along the way, and whether a change in that journey could make the AI less safe?
Data quality is about fitness for use, not perfect data
Clinical data are rarely perfect. A medical record reflects real care: information is entered by different professionals, at different times, for different purposes and through different systems. Some fields are mandatory and others optional. Some data are structured, while important information may remain in narrative text. Values may be copied forward, corrected later or entered after the clinical event, and different departments may use different documentation conventions.
The relevant question is not whether the dataset is free from every imperfection. It is whether those imperfections matter for the specific AI task. A missing variable may be relatively unimportant for one system and safety-critical for another. A two-hour delay may have little consequence for an administrative forecasting tool but be unacceptable for a deterioration-prediction system. A diagnosis code useful for billing may not contain the clinical detail needed by a decision-support model.
Recent work on electronic health record data quality reinforces this lifecycle view. A 2026 framework for transparent reporting of data-quality assessment across the clinical EHR lifecycle emphasizes that problems may arise at different stages between initial data generation and later reuse, and that examining data only at the point of AI use can obscure where the problem originated. The framework considers dimensions such as completeness, conformance and plausibility, as well as contextual and system-level factors including timeliness, relevance, accessibility, governance, operating platform and interoperability [8]. A 2026 IEEE Standards Association white paper similarly places data quality and governance at the foundation of trustworthy AI-supported healthcare decision-making [10]. For clinical AI, data quality is therefore contextual. The organization needs to know not only whether a field is populated, but whether it is sufficiently reliable for the clinical function the AI is being asked to support.
Data lineage answers a different question: what happened to the data before the AI saw it?
A clinical value rarely travels directly from the bedside into an AI model. Consider a laboratory result. It may originate in an analyzer, enter a laboratory information system, pass through an interface engine, map to an internal code, enter the electronic medical record, be transformed into another data format and then be transmitted through an API into an AI application.
At several points along that path, the value can change without becoming visibly “wrong” to the surrounding systems. A unit may be normalized, a code mapped, a timestamp reformatted, a text result converted into a category, a missing value assigned a default, duplicate results filtered, or several measurements aggregated into one input. Data lineage makes those transformations visible. A useful lineage record should allow the organization to answer questions such as: What system generated this value? Which field or code represented it there? What transformations occurred? Which interface moved it? Which version of the mapping was used? When did the AI receive it?
The 2026 CARE Data Checklist and Data Lineage methodology developed for clinical laboratories provides a useful example. It supports documentation of dataset composition, demographics, collection methods, labeling processes, usage constraints, maintenance requirements and data readiness, while using lineage to connect technical and clinical stakeholders across the AI lifecycle [7]. The framework was developed for clinical laboratory AI and should not be treated as a universal healthcare standard, but its central principle remains relevant across settings: AI inherits important characteristics and limitations from the data on which it depends. Data lineage also complements, rather than replaces, other forms of AI provenance. Provenance of an AI-generated clinical output may ask how the system contributed to a recommendation, prediction or documentation event. Input data lineage asks how the information used by the AI reached the system in the first place.
Missingness is not simply an empty cell
Missing data are among the easiest problems to count and among the easiest to misunderstand. A field can be missing because a clinician did not enter it, because the test was never ordered, because another facility performed the test, because an interface failed, because the patient was not eligible for the assessment, or because a redesigned workflow moved the information somewhere else in the record. These situations are not clinically equivalent.
In healthcare, the fact that something is missing can itself carry information. If an AI pipeline automatically replaces every missing value with zero, “not measured” can accidentally become “normal.” If an EMR redesign changes where clinicians record a variable, the apparent missingness pattern seen by the model may shift even though clinical practice has not materially changed. Healthcare organizations should therefore avoid treating completeness as a simple percentage. For important AI inputs, they should understand why values can be missing, whether missingness differs across sites or patient groups, how absence is represented, how the system handles it and whether those patterns change over time.
This becomes especially important when imputation occurs inside a vendor's product. “The model handles missing data” is not enough information for safe deployment. The healthcare organization should understand the operational consequences of absence: whether the system distinguishes missing, unknown, not applicable and true zero values, and what happens to the output when a clinically important input is unavailable. A sudden improvement in completeness can also be a warning rather than good news. It may reflect better documentation, but it could also mean that a software update has begun automatically populating a default value. Data-quality monitoring needs enough clinical context to distinguish those possibilities.
Coding changes can create semantic drift without changing the model
Clinical AI depends not only on values but also on what those values mean. Hospitals use diagnosis codes, procedure codes, medication identifiers, laboratory codes, local service codes, categories, flags and many other structured representations. These representations are not necessarily stable over time. A code can be retired. A local code can be remapped. A category can be split into two. A field that previously meant “current smoker” may later represent broader tobacco exposure. A laboratory test can move to another platform with a different method or reference range. A medication dictionary can change product identifiers. To a human working within the clinical system, the change may appear small; to an AI pipeline, it may alter the meaning of an input.
This is a form of semantic drift: the data element still exists, but what it represents has changed. Healthcare organizations should therefore treat material changes in coding dictionaries, units, reference ranges, category definitions and mapping logic as potential AI change events. The governance question should not only be, “Did the AI model change?” It should also be, “Did the meaning of anything feeding the AI change?”
Version control is important here. If a mapping table converts local laboratory codes into model inputs, the organization should know which mapping version is active and what changed between versions. The same principle applies to transformations performed by the vendor. Without versioned lineage, retrospective investigation becomes much harder: a hospital may know that the model generated an unexpected output but be unable to reconstruct which representation of the source data reached it at the time.
AI performance can deteriorate even when the model itself has not changed
Different forms of change are often grouped loosely under the word “drift,” but distinguishing them is useful. Concept drift can occur when the relationship between inputs and outcomes changes. Data drift can occur when the distribution of incoming data changes. There is also a more operational problem: the data pipeline itself may change, degrade or fail.
A data feed may stop. A field may begin arriving late. An API can truncate information. Units may be converted incorrectly. A database join can duplicate patients. Timestamps can shift because of timezone handling. An interface migration can silently drop a category. A vendor update can change the expected schema. The AI may continue running despite the problem.
Healthcare organizations should therefore monitor data-pipeline health separately from model-performance health. Useful signals may include input volume, missingness, unexpected nulls, category distributions, range violations, unit consistency, mapping success, duplicate rates, data freshness, timestamp patterns, schema changes and interface errors. None of these metrics alone establishes that an AI system is safe or unsafe; their value is that they can provide early warning that the information environment has changed. In this article, pipeline drift is used as a practical governance term for material changes in the generation, transformation or transmission of information reaching the AI. It should not be understood as a formally standardized regulatory term.
Data quality starts where the data are created
It is tempting to treat AI data quality as an IT responsibility. In practice, that starts too late. A data engineer may discover that 20% of a field is missing but may not know that clinicians document the same concept elsewhere. An AI vendor may see inconsistent values without knowing that two clinical departments use different workflows. A quality team may understand the clinical process but not realize that an interface transformation changes the value before it reaches the model.
Data quality therefore requires shared ownership. The EHR lifecycle framework published in 2026 distinguishes organizations where data are generated from those that later receive or reuse the data, illustrating why an assessment conducted at only one point can miss problems introduced elsewhere [8]. A separate 2026 study in the Journal of Biomedical Informatics proposed a lifecycle-integrated governance model that embeds controls upstream in clinical data generation rather than relying primarily on post-hoc correction [9].
For a healthcare organization, practical ownership may involve clinicians, health-information management, laboratory or imaging services, pharmacy, IT, data engineering, cybersecurity, quality and patient safety, and the AI governance function. The people closest to data generation often understand what the information means, while technical teams understand what happens to it after it leaves the source system. Safe AI governance needs both perspectives.
Viet Nam's AI framework makes data quality directly relevant to high-risk AI
Viet Nam's Law on Artificial Intelligence No. 134/2025/QH15 has been effective since 1 March 2026, while Decree No. 142/2026/NĐ-CP has been effective since 1 May 2026 [1,2]. The framework uses a risk-based approach rather than treating every AI system in the same way.
For high-risk AI systems, Article 15 of Decree No. 142 requires providers to establish and maintain a risk-management system appropriate to the intended use, deployment scope and risk level. Among its minimum requirements is ensuring the quality, suitability and representativeness of training, testing and evaluation data, to the extent necessary to limit risks arising from data. Risk-management measures must also be reviewed and updated when there are significant changes to the model, data, operating method or intended use [2].
This requirement needs to be interpreted carefully. The express data-quality language in Article 15 concerns training, testing and evaluation data; it should not, by itself, be read as a statutory requirement for the specific runtime-input monitoring or data-lineage controls proposed in this article. At the same time, operational data changes can have regulatory significance for high-risk systems. Under Article 13, a significant change to the main data sources, principal input data types or data-processing methods that materially affects system operation or risk is one of the specified circumstances requiring the provider to reassess conformity [2].
Deployers of high-risk systems have separate operational responsibilities. These include operating the system within the intended conditions and limitations defined by the provider, monitoring for deviations, risks or incidents, maintaining human oversight and intervention mechanisms, taking risk-control measures within their authority when new risks arise, and coordinating with the provider when significant changes or incidents require risk controls to be reviewed [2].
The boundaries of “high-risk” also matter. Decision No. 33/2026/QĐ-TTg, effective from 15 August 2026, establishes Viet Nam's current formal list of high-risk AI systems [3]. As of this review, its healthcare section identifies specified AI-assisted surgical and robotic-surgery systems under defined conditions. It does not classify every AI application used in healthcare as high-risk merely because it operates in a healthcare setting. Healthcare organizations should therefore determine the applicable legal classification of the particular system and use case rather than assume high-risk status from the sector alone.
These distinctions matter because Vietnamese AI legislation does not currently establish a universal statutory data-lineage checklist for every healthcare AI system. Data-quality and lineage controls may nevertheless be appropriate beyond the minimum legal requirements when they are proportionate to clinical risk and used as patient-safety controls.
Viet Nam is also developing national datasets for AI
Decision No. 804/QĐ-TTg, issued on 6 May 2026, established the national list of datasets to support AI development in essential sectors [4]. The framework includes healthcare and health datasets and signals a broader national direction toward creating, standardizing and governing data for AI development.
The healthcare scope includes clinical, paraclinical and imaging data; public health and prevention; medicines, devices, supplies and food safety; specialist knowledge, guidance and research; and sector governance, workforce and databases. The Decision also identifies priority areas that include medical imaging data, AI testing and evaluation datasets, and datasets supporting AI safety and trustworthiness [4].
The agencies responsible for developing these datasets are expected to organize their collection and creation, ensure data quality in accordance with applicable requirements, and undertake activities such as labeling, annotation and standardization. Collection, sharing, processing, use and exploitation must remain consistent with applicable legislation on data, personal-data protection, state secrets, intellectual property and other relevant areas [4].
For hospitals and other healthcare organizations, Decision No. 804 should primarily be understood as part of Viet Nam's national AI-data policy direction. It does not directly require every healthcare organization to build the specific internal data-lineage framework proposed in this article. Its broader message is nevertheless relevant: useful and trustworthy AI depends on data that can be appropriately created, standardized, governed and understood.
Electronic medical records increase the importance of source-data governance
Circular No. 13/2025/TT-BYT has governed the implementation of electronic medical records since 21 July 2025 and remains in force [5]. It requires electronic medical records to contain the required medical-record information and to comply with applicable legislation on healthcare, data, information technology, electronic transactions, information security, cybersecurity, access to information, personal-data protection and data storage. Its technical requirements also include readiness to recover data and retrieve information from the electronic medical record when needed for treatment, inspection, scientific research and health management.
As healthcare organizations become more dependent on structured digital records, those records increasingly become upstream sources for AI. That creates an important distinction: an EMR can function adequately for ordinary clinical use while still producing data that are problematic for a particular AI application. A clinician may understand the context of an unusual value; the model may not. A field may be adequate for human reading but inconsistently encoded for automated use.
Healthcare organizations should therefore not equate “the data are in the EMR” with “the data are fit for AI.” AI readiness requires another layer of assessment that considers the intended AI use, the reliability of critical fields and the way information travels from the source record into the model.
Data lineage should not become an excuse to collect or retain everything
More traceability is not automatically better governance. A lineage system needs enough information to reconstruct important transformations and investigate problems, but it does not necessarily require copying every clinical datum into another repository or retaining raw information indefinitely.
Viet Nam's Law on Personal Data Protection No. 91/2025/QH15 has been effective since 1 January 2026 [6]. Healthcare organizations therefore need to design lineage and quality controls in ways that remain consistent with applicable requirements for personal-data processing and protection, alongside other relevant duties governing medical and health information.
The goal is traceability, not unnecessary duplication. For some systems, a substantial part of the lineage record may consist of metadata: source system, source field, mapping version, transformation rule, timestamp, destination field and processing status. That can provide meaningful operational traceability without creating another uncontrolled clinical dataset. The level of detail should be proportionate to the clinical significance of the input, the system's risk and the organization's legitimate investigation needs.
Vendors should disclose the data contract, not only the model specification
Healthcare organizations often receive considerable information about an AI model while receiving much less information about the interface and data assumptions on which the product depends. That is a governance gap. For clinically consequential AI, vendor due diligence should identify the required and optional data elements, expected units and formats, accepted code systems, timing requirements, permissible ranges, mapping assumptions, missing-value representation and behavior when inputs fall outside specification. This can be thought of as a data contract between the healthcare organization and the AI system.
The organization should also understand what happens when that contract is violated. Does the system reject the input, generate a warning, continue operating, substitute a default, use the most recent available value or return an output with reduced confidence? A silent fallback can be more difficult to govern than a visible failure. Vendor agreements and change-management processes should therefore address notification when expected schemas, APIs, transformations, mapping logic or data requirements materially change. A model can remain on the same version while the interface around it changes substantially.
Data quality needs operational thresholds, not only dashboards
A dashboard showing missingness and input distributions is useful, but governance ultimately requires decisions. Healthcare organizations need to know what should happen when an important data-quality signal crosses an agreed threshold. If a critical field that is normally 98% complete falls to 75%, should the AI continue operating? If one laboratory stops sending data for six hours, can the model safely continue with reduced information or should its use be restricted? If a unit distribution changes overnight, who investigates? If mapping success falls after an interface update, who has the authority to stop or limit use?
Thresholds should be linked to the clinical significance of the input and informed by validation and real-world monitoring rather than chosen arbitrarily. Not every field requires the same sensitivity. A data element central to the AI's clinical function may justify rapid investigation or suspension; a lower-impact contextual field may justify continued operation with monitoring.
A useful governance chain is:
data-quality signal → defined threshold → accountable owner → investigation → clinical impact assessment → continue, restrict or stop.
The purpose of a threshold is not simply to generate an alert. It is to connect an observable change in data to an accountable safety response.
A practical minimum data-quality monitoring set
Healthcare organizations do not need to monitor every conceivable statistic. For clinically consequential AI, a practical monitoring set can begin with:
Completeness: Are expected inputs present, and has missingness changed?
Conformance: Are values arriving in the expected format, code system and schema?
Plausibility: Are values within clinically and technically credible ranges?
Timeliness: Are data sufficiently current for the AI's intended use?
Consistency: Do logically related fields agree where they should?
Uniqueness and identity: Are duplicate records, patient-matching errors or record-linkage problems occurring?
Unit integrity: Are units, reference ranges and conversion rules stable?
Category and code stability: Have dictionaries, categories, mappings or coding conventions changed?
Distribution: Are important input distributions shifting over time, across sites or across relevant patient groups?
Pipeline health: Are interfaces, APIs, transformations and mapping processes completing as expected?
Lineage completeness: Can the organization trace a clinically important input back through the transformations that produced it?
These are practical governance dimensions, not statutory metrics prescribed by Vietnamese AI legislation. The exact measures, thresholds and monitoring frequency should reflect the intended use, technical architecture and clinical consequences of failure.
Data-quality incidents should be treated as potential AI safety incidents
When an AI system produces an unexpected output, organizations may understandably begin by investigating the model. Sometimes the model is not where the problem began. A wrong value may have been entered upstream. An interface may have associated information with the wrong patient. A laboratory unit may have changed. A pipeline may have duplicated records. The AI may have processed exactly what it received.
Incident investigation therefore needs the ability to work backward through the data lineage. For a clinically significant event, useful questions include: What input did the model receive? Was that input correct at the source? What transformations occurred? Did the system receive the expected version, units and timestamps? Were important values missing? Did a pipeline or mapping change recently? Could the same problem have affected other patients?
This is where data lineage becomes more than documentation. It becomes part of a forensic patient-safety capability. If an organization discovers that a mapping error affected an AI input for several weeks, lineage combined with deployment, operational and output logs can help identify which outputs and patient encounters may have been exposed and support a targeted retrospective review. Without that traceability, an organization may know that something went wrong without being able to establish where the problem began, when it began or how far it spread.
Data changes should trigger AI change control when they can affect safety
Not every database change requires AI revalidation. But changes that materially alter the meaning, availability, distribution or processing of important inputs should enter the organization's AI change-control pathway. Examples can include a new laboratory analyzer or reference range, a change in units, new diagnostic or medication coding conventions, redesigned EMR fields, revised mapping tables, new patient-identification logic, changes in integration middleware, new data sources, an API version change, altered imputation rules or a meaningful change in the population generating the data.
The appropriate response may range from a documented review to targeted regression testing, local revalidation, additional monitoring or temporary restriction of the AI. The central question is: Could this data change make the evidence supporting our previous AI validation or safety case less reliable?
If the answer is yes, the change deserves AI-governance review even when the underlying model code has not changed. For high-risk AI systems, this principle also aligns with Viet Nam's current regulatory framework: Article 13 of Decree No. 142 specifically identifies significant changes to data sources, principal input data types or data-processing methods that materially affect operation or risk as circumstances requiring conformity reassessment [2].
A practical Clinical AI Data Quality and Lineage Gate
Before deployment, and again when an important data source, workflow or pipeline changes, healthcare organizations can ask:
Intended use: Which clinical decision, prioritization, prediction or documentation function depends on these data?
Critical inputs: Which data elements materially influence the AI output or the safety of the workflow?
Source: Where is each critical input originally created, and who is responsible for the source process?
Definition: What does each data element mean clinically and technically?
Missingness: Why can the value be missing, and how does the AI handle different forms of absence?
Units and ranges: Are units, reference ranges and conversion rules explicitly defined and monitored?
Codes and categories: Which code sets, dictionaries and mappings are used, and are they version controlled?
Transformations: What calculations, normalization, aggregation, filtering, imputation or mapping occur before the AI receives the data?
Identity: How is the correct patient, encounter, specimen, image or record maintained across systems?
Timeliness: How old can the data be before they are no longer appropriate for the intended AI use?
Lineage: Can the organization reconstruct the path from source system to model input when an incident occurs?
Pipeline monitoring: Which data-flow failures can be detected automatically, and which require human review?
Thresholds: What changes in completeness, distribution, latency, units, mapping or other quality indicators trigger investigation?
Authority: Who can restrict or suspend use of the AI when data integrity is uncertain?
Vendor dependencies: Which transformations or imputations occur inside the vendor's system, and are they sufficiently transparent to the healthcare organization?
Local validation: Did validation use data that reflect the definitions, units, mappings and workflows used in routine deployment?
Subgroups and sites: Does data quality differ materially across sites, clinical services or relevant patient groups?
Change control: Which changes to EMRs, interfaces, coding, laboratory systems or data pipelines require AI-governance review?
Incident response: Can the organization identify which outputs and patient encounters may have been exposed if a data-quality problem is discovered retrospectively?
Data protection: Can adequate lineage be maintained without retaining or duplicating unnecessary personal information?
The Clinical AI Data Quality and Lineage Gate is a practical organizational governance framework proposed for implementation and patient-safety purposes. It is not a statutory checklist or a legally prescribed data-lineage model under Vietnamese law.
What this means for healthcare organizations in Viet Nam
The timing of this issue matters. Viet Nam is expanding the use of electronic medical records, implementing a formal risk-based AI regulatory framework and developing national datasets for AI in essential sectors. Circular No. 13/2025/TT-BYT provides the current framework for electronic medical-record implementation; the AI Law, Decree No. 142 and Decision No. 33 establish a risk-based regulatory architecture that includes specific obligations for high-risk AI systems; and Decision No. 804 places healthcare and health data within the country's national AI-data development agenda [1-5].
These developments create important opportunities, but more digital data do not automatically produce safer AI. Clinical AI depends on information generated through ordinary care. A sophisticated model cannot reliably compensate for a laboratory unit that changed silently, a field whose meaning was redesigned, an interface that stopped transmitting an important category, or a missing value that was converted into the wrong signal.
That makes data quality a governance responsibility rather than an IT housekeeping task. Healthcare organizations using clinically consequential AI should be able to answer: What data does this system depend on? Do those data still mean what we think they mean? What has happened to them before they reach the AI? And how quickly would we know if that changed?
The most useful leadership question is therefore not simply, “Is our AI system still running?” It is, “Can we trust the data reaching it — and can we reconstruct where those data came from?”
That is where clinical AI data governance becomes patient safety.
Professional education notice
This article is intended for professional education and knowledge exchange. It does not constitute individualized legal, regulatory, clinical, cybersecurity, data-governance or medical-device advice.
The terms data quality, data lineage, semantic drift, pipeline drift, data contract and the Clinical AI Data Quality and Lineage Gate are used here as practical data-governance and patient-safety concepts. The framework proposed in this article is not a statutory checklist required by Vietnamese AI legislation.
Article 15 of Decree No. 142/2026/NĐ-CP contains specific data-quality requirements within the risk-management obligations applicable to providers of high-risk AI systems, including requirements relating to training, testing and evaluation data. Those provisions should not be generalized to mean that every healthcare AI application is legally high-risk or subject to identical statutory requirements. Decision No. 33/2026/QĐ-TTg establishes the current formal list of high-risk AI systems, including specified healthcare systems. Healthcare organizations may nevertheless adopt broader runtime data-quality and lineage controls as proportionate internal patient-safety measures.
Decision No. 804/QĐ-TTg establishes a national policy framework and dataset list for AI development in essential sectors, including healthcare. It should not be interpreted as directly imposing the internal lineage framework proposed here on every healthcare organization. International frameworks and studies cited in this article are included as evidence and implementation references and should be adapted to local clinical workflows, technical architecture, terminology and applicable Vietnamese law.
References
[1] National Assembly of Viet Nam. Law No. 134/2025/QH15 on Artificial Intelligence. Adopted 10 December 2025; effective 1 March 2026.
[2] Government of Viet Nam. Decree No. 142/2026/NĐ-CP Detailing a Number of Articles and Measures for Implementation of the Law on Artificial Intelligence. Issued 30 April 2026; effective 1 May 2026.
[3] Prime Minister of Viet Nam. Decision No. 33/2026/QĐ-TTg Promulgating the List of High-Risk Artificial Intelligence Systems. Issued 30 June 2026; effective 15 August 2026.
[4] Prime Minister of Viet Nam. Decision No. 804/QĐ-TTg Promulgating the List of Datasets for Artificial Intelligence Development in Essential Sectors. Issued and effective 6 May 2026.
[5] Ministry of Health of Viet Nam. Circular No. 13/2025/TT-BYT Providing Guidance on Implementation of Electronic Medical Records. Issued 6 June 2025; effective 21 July 2025.
[6] National Assembly of Viet Nam. Law No. 91/2025/QH15 on Personal Data Protection. Adopted 26 June 2025; effective 1 January 2026.
[7] Garcia CA, Reed KA, Lantz E, et al. The CARE framework for AI dataset documentation in clinical laboratories: a comprehensive checklist and data lineage methodology. American Journal of Clinical Pathology. 2026;165(5).
[8] Wassell M, Butler-Henderson K, Verspoor K. A Framework for Transparent Reporting of Data Quality Analysis Across the Clinical Electronic Health Record Data Lifecycle. Studies in Health Technology and Informatics. 2026;339:76–81.
[9] Li X, Li L, Yang C, et al. Towards Reliable Clinical Data: A Collaborative Data Governance Architecture with Lifecycle Integration. Journal of Biomedical Informatics. 2026;179:105046.
[10] IEEE Standards Association. Global Data Quality and Governance as the Cornerstone of AI Decision Support in Healthcare. IEEE White Paper. Published 28 July 2026.