Local Validation of Clinical AI in Viet Nam: A Practical Framework for Performance, Safety and Workflow Fit Before Routine Use
PRACTICAL FRAMEWORKS & TOOLS
Local Validation of Clinical AI in Viet Nam: A Practical Framework for Performance, Safety and Workflow Fit Before Routine Use
PRACTICAL FRAMEWORKS & TOOLS
Last reviewed: 1 October 2026
A clinical AI system can have strong published evidence, regulatory authorization in another country and impressive vendor-reported performance and still not work as expected in a particular Vietnamese healthcare organization. Clinical AI does not operate in an abstract environment. It encounters real patients, local disease prevalence, Vietnamese clinical practice, specific devices, data formats, image-acquisition protocols, documentation habits, referral patterns, network infrastructure and clinicians who may interact with the technology differently from those in the studies used to develop or evaluate it.
This does not mean that every healthcare organization needs to repeat the developer’s clinical studies before using an AI system. It does mean that external evidence and regulatory status should not automatically be treated as proof of local performance. The practical question is: Do we have enough locally relevant evidence to be confident that this AI system performs acceptably, fits our workflow and can be used safely for the purpose we intend?
That question is becoming increasingly important in Viet Nam. The Law on Artificial Intelligence No. 134/2025/QH15 has been effective since 1 March 2026, Decree No. 142/2026/NĐ-CP since 1 May 2026, and Decision No. 33/2026/QĐ-TTg establishing the current list of high-risk AI systems since 15 August 2026.[1–3] Viet Nam’s current framework classifies AI systems according to risk and imposes additional requirements on systems classified as high-risk. Decree No. 142 also requires the deployer to coordinate with the provider to review and, where necessary, reclassify a system when deployment, modification, integration or changes in function or intended purpose create new or higher risks than those previously classified.[2]
International guidance points in the same direction. IMDRF’s 2025 Good Machine Learning Practice principles emphasize representative intended populations, clinically relevant testing conditions, human–AI interaction and monitoring after deployment. Joint FDA, Health Canada and MHRA transparency principles also identify local site-specific acceptance testing or validation as information that may help organizations maintain safe and effective use over the product lifecycle.[8,10] Local validation should therefore be understood as part of responsible implementation, not simply as an administrative box to tick before go-live.
Local validation is not the same as regulatory conformity assessment
An important distinction is needed at the outset. In this article, local validation means an organizational process used by a healthcare organization to determine whether an AI system performs adequately and can be used safely in its own population, technical environment and clinical workflow. It is not the same as the statutory conformity assessment applicable to AI systems classified as high-risk under Viet Nam’s AI Law.
As a general rule, Article 13 of the Law requires high-risk AI systems to undergo conformity assessment before being put into use and when significant changes occur. Depending on the applicable category, that assessment may need to be performed by a registered or recognized conformity-assessment organization, or the provider may conduct the assessment itself or engage such an organization.[1] Decree No. 142 provides further requirements for classification and conformity assessment and recognizes, within defined limits, relevant results obtained under specialized laws, technical regulations or product-quality legislation so that the same content does not have to be assessed again unnecessarily.[2] Decision No. 33 also contains transitional arrangements for certain systems already operating or introduced during the defined transition period, so the timing of compliance obligations should be assessed for the particular system rather than applying the general pre-use rule without qualification.[3]
As of 1 October 2026, clinical use alone does not make an AI system high-risk under Viet Nam’s current framework. The healthcare section of Decision No. 33/2026/QĐ-TTg currently identifies two specified categories involving AI-supported surgery and surgical robots under defined conditions. These include AI integrated into robots that directly participate in or guide interventions, and AI-controlled robotic systems that directly execute treatment-related actions under specified levels of automation.[3] Other clinical AI systems may nevertheless be subject to other provisions of the AI Law and to medical-device, personal-data, cybersecurity or other sector-specific requirements depending on what the system does and how it is deployed.
Local validation does not replace regulatory authorization, applicable medical-device requirements, statutory conformity assessment or vendor validation. Conversely, regulatory status does not necessarily answer whether a system will perform adequately in a particular hospital or clinic. These processes may support each other, but they answer different questions.
Start with the intended use, not the accuracy number
Local validation should begin before anyone chooses a performance metric. The organization first needs to define precisely what the AI will do: which patients it will be used for, where in the care pathway it will operate, who will see the output, and whether it will screen, detect, prioritize, predict, recommend, document or directly influence an intervention. The organization should also understand whether the AI is advisory, whether any action can occur automatically, and what should happen when a clinician disagrees with its output.
A model described simply as “AI for lung cancer” or “AI for endoscopy” is not sufficiently defined for meaningful validation. Consider an AI system designed to detect possible lesions during colonoscopy. The local question might be whether it can provide sufficiently reliable real-time detection with the organization’s actual endoscopy equipment, image quality, bowel-preparation conditions, case mix and workflow without producing an unacceptable level of distraction or false-positive alerts. That is very different from asking whether “the AI has 95% accuracy.”
The intended use determines what should be measured, what errors matter most and how much uncertainty can reasonably be accepted.
External evidence should be tested for transportability
The first task is not necessarily to generate new evidence. It is to determine how well the existing evidence applies locally. Healthcare organizations should understand where the system was developed and validated, what populations were represented, the clinical settings involved, disease prevalence, equipment and data sources, the reference standard, sample size and study design, and whether evaluation occurred retrospectively, prospectively or under routine clinical conditions.
A system developed primarily in large academic hospitals outside Viet Nam may perform very well in Viet Nam. But that conclusion should come from evidence rather than assumption. Differences that may matter include patient characteristics, disease spectrum, referral patterns, prevalence, image-acquisition protocols, laboratory methods, medical equipment, language, documentation structure and clinical workflow. Natural-language systems can be particularly sensitive to local terminology, abbreviations, Vietnamese language use and mixed Vietnamese–English clinical documentation.
IMDRF’s 2025 GMLP principles emphasize that datasets used in clinical evaluation should sufficiently represent the intended patient population, use environment and measurement inputs so that performance can reasonably generalize to the intended population.[8] A more useful question is therefore not simply “Was this AI validated?” but “Validated for whom, using what data, in what environment and for what clinical purpose—and how similar are those conditions to ours?”
Technical acceptance should come before clinical conclusions
An AI system cannot be meaningfully assessed locally if the information reaching it is technically different from what the system expects. Healthcare organizations should first confirm that data are transferred correctly, required inputs are complete, units and formats are interpreted properly, interfaces function as intended, timestamps remain reliable and outputs reach the correct user at the correct point in the workflow.
For imaging AI, this may include compatibility with modality manufacturers, acquisition protocols, image resolution, reconstruction settings or PACS integration. For laboratory or risk-prediction systems, it may include variable definitions, units, missing-data handling and mapping between local information systems and the inputs expected by the model. For generative or language-based clinical AI, technical evaluation may need to examine whether the system receives the intended clinical context and whether information can be lost, truncated, incorrectly mapped or inadvertently mixed across patients or encounters.
A model can remain mathematically unchanged while its real-world performance changes because the inputs or surrounding system have changed. Local validation therefore needs to evaluate the deployed system, not merely the algorithm described in a publication.
There is no universal performance metric for clinical AI
One of the most common mistakes in AI evaluation is allowing one attractive metric to dominate the decision. Area under the receiver operating characteristic curve, sensitivity, specificity, positive predictive value, negative predictive value, calibration, precision, recall and other measures answer different questions, and their relevance depends on the intended use.
For a screening application where missing an important condition could have serious consequences, sensitivity may deserve particular attention. For a system generating frequent alerts, specificity and positive predictive value may become operationally important because excessive false positives can create alert fatigue and unnecessary work. For a risk-prediction model, calibration can be critical because a predicted probability should meaningfully correspond to observed risk in the population where the system is used. Predictive values are also influenced by prevalence, meaning that a system with unchanged sensitivity and specificity can produce different positive predictive values in different clinical populations.
For detection or localization systems, performance may need to be assessed at patient, examination, image or lesion level. For generative AI, conventional diagnostic metrics may be inappropriate; evaluation may instead consider clinically important omissions, factual errors, unsupported statements, potentially harmful recommendations, completeness, consistency and how much human correction is required.
The right question is not simply “What is the AI’s accuracy?” It is “Which performance characteristics matter for the clinical decision we are asking this system to support?”
Acceptance criteria should be defined before reviewing local results
Validation becomes less credible when the definition of success is created after the results are known. Before examining local performance, the organization should ideally define what would be considered acceptable, what would require additional investigation and what would prevent routine use.
Thresholds should reflect clinical consequences rather than convenience. A false negative in a low-impact administrative classification task is not equivalent to a false negative in a system intended to identify a time-critical clinical condition. Where useful, acceptance criteria may include statistical performance, clinically important failure rates, maximum tolerable latency, data-quality requirements, system availability, subgroup performance, user comprehension and workflow measures.
Not every criterion needs a single numerical threshold. Some questions may appropriately require structured clinical judgment. The important point is to define the decision logic in advance rather than lowering or changing expectations simply because an organization wants a project to proceed.
The reference standard must be credible
An AI system can only be evaluated against a reference that is appropriate for the clinical question being tested. Depending on the use case, the reference standard may be pathology, laboratory confirmation, longitudinal clinical outcome, a validated measurement, independent expert review, adjudication by multiple clinicians or another accepted clinical method.[9]
The “doctor’s answer” should not automatically be treated as ground truth. Clinicians can disagree, and retrospective records can contain errors or incomplete information. When interpretation is subjective, an organization may need predefined adjudication procedures or clearly stated criteria for resolving disagreement.
The organization should also understand whether local cases used for evaluation could previously have been available to the developer or included in training, tuning or development datasets. Where independence cannot reasonably be established, apparent performance may be more optimistic than expected with genuinely unseen data.
Average performance can hide clinically important failures
A system that performs well overall may still perform poorly for a smaller group of patients or under particular operating conditions. Local validation should therefore examine relevant subgroups where the sample size and clinical context allow meaningful evaluation. Depending on the technology, these may include age groups, sex, disease severity, common comorbidities, inpatient versus outpatient settings, equipment types, sites, operators or other clinically relevant characteristics.
The aim is not to generate subgroup analyses indiscriminately. Small samples can produce unstable and misleading estimates. The objective is to identify plausible circumstances in which performance could differ and determine whether those differences matter for patient care.
Technical edge cases deserve similar attention. What happens with poor-quality images, missing values, unusual anatomy, emergency cases, patients outside the intended population or a less common device or software configuration? Good validation looks deliberately for where the system may fail, not only for situations in which it performs well.
The human-AI team may matter more than the model alone
Clinical AI rarely operates in isolation. A technically high-performing model may provide little benefit if clinicians do not understand its outputs, results arrive after the relevant decision has already been made, or repeated false alarms cause users to ignore the system. Conversely, a model with more modest standalone performance may still add clinical value if it reliably directs attention to cases that deserve closer review.
IMDRF’s GMLP principles explicitly emphasize evaluation of the human-AI team in the intended use environment rather than focusing only on the model in isolation.[8] Local evaluation should therefore consider whether users understand what an output means and what it does not mean, whether they can recognize inappropriate outputs, whether AI advice changes decisions in the intended way, and whether users become overly reliant on the system or routinely ignore it. Organizations should also examine alert fatigue, cognitive burden, workarounds and whether use of the technology creates additional work elsewhere in the care pathway.
This is where local validation becomes more than a statistical exercise. An AI system can pass technical performance testing and still fail clinically because it does not fit how care is actually delivered.
A staged validation approach can reduce risk
Healthcare organizations do not need to expose patients immediately to unrestricted routine clinical use simply to learn whether a system works locally. Depending on the technology and level of uncertainty, evaluation can progress in stages.
A retrospective local evaluation can test the system against previously collected local cases without influencing current patient care. This may provide early information about technical compatibility, local performance and possible failure patterns. A prospective silent or shadow evaluation can then allow the system to process real-world cases while its outputs are withheld from clinical decision-making, helping identify issues with data quality, workflow timing, latency and performance that are difficult to reproduce retrospectively. If the evidence remains favorable, a limited live implementation may then be used to assess human–AI interaction and workflow under controlled organizational conditions before broader routine use.
Not every AI system needs all three stages. A lower-risk tool with strong external evidence and limited influence on patient care may justify a lighter process, while higher-risk applications, novel technologies or systems with substantial residual uncertainty may require considerably stronger evaluation. The principle is proportionality: the greater the potential patient harm and the greater the remaining uncertainty, the stronger the validation should be.
A limited hospital or clinic implementation should also not automatically be treated as the formal controlled-testing mechanism established under Article 21 of Viet Nam’s AI Law and Chapter IV of Decree No. 142/2026/NĐ-CP. Participation in that statutory mechanism is a distinct regulatory pathway and is voluntary under the Decree; whether it is relevant to a particular activity requires a separate assessment of the actual project and legal circumstances.[1,2]
Local validation should examine workflow fit explicitly
Workflow fit is sometimes treated as an implementation issue to address after technical evaluation. That is too late. If AI is expected to influence clinical care, the pathway between its output and the clinical action is part of the system being evaluated.
The organization should understand where the AI enters the workflow, when the result becomes available, who sees it, what that person is expected to do, and what happens when the AI output conflicts with clinical judgment. A five-second delay may be irrelevant for one application and unacceptable for another. A useful alert displayed in a separate dashboard that clinicians rarely open may have almost no real-world effect. An AI-generated report requiring extensive manual verification may save less time than expected. Repeated false-positive alerts can change clinician behavior even when headline performance metrics remain good.
Workflow evaluation should therefore consider usability, latency, interruptions, cognitive burden, workarounds, override patterns and whether meaningful human oversight remains realistic under normal workload. The question is not merely whether an AI can be integrated into the organization’s IT system. It is whether it can be integrated safely into clinical work.
Using local patient data requires a separate data-governance review
Local validation frequently relies on patient data, creating an additional governance layer. Viet Nam’s Law on Personal Data Protection No. 91/2025/QH15 and Decree No. 356/2025/NĐ-CP have been effective since 1 January 2026.[4,5] Under Decree No. 356, health-status data are included in the category of sensitive personal data, meaning organizations handling such information should pay particular attention to applicable processing requirements, access restrictions, procedures and security safeguards.[5]
Where local validation involves personal data, healthcare organizations should assess the actual purposes of processing, the roles of participating organizations, data flows, access controls, security arrangements and any involvement of vendors, cloud infrastructure or cross-border processing. A project should not assume that simply calling an activity “validation,” “quality improvement” or “pilot” automatically resolves data-protection obligations.
Where de-identification, pseudonymization or data minimization is used, the organization should understand what those measures actually achieve in the specific technical environment rather than treating them as generic exemptions from data-protection requirements. The amount and type of data collected should also be proportionate to the validation purpose; collecting more patient information than necessary does not make an evaluation scientifically stronger.
Medical-device status remains a separate question
Some clinical AI systems may also fall within Viet Nam’s medical-device framework. Where software is regulated as a medical device, compliance with the AI framework does not replace applicable medical-device requirements, and medical-device status does not remove AI-specific obligations where those obligations also apply.
Viet Nam’s current medical-device framework continues to be based on Decree No. 98/2021/NĐ-CP, as amended, with the consolidated framework reflected in Consolidated Document No. 08/VBHN-BYT issued in March 2026.[6] Circular No. 24/2026/TT-BYT, effective from 1 July 2026, further addresses the determination of risk levels and management measures for products and goods that are medical devices and amends parts of the implementing framework.[7]
Healthcare organizations should therefore understand a product’s regulatory status, declared intended purpose and applicable conditions of use before deciding how it should be locally evaluated. Local validation should not be used to legitimize use outside a product’s declared or authorized intended purpose or scope where applicable, or to justify a material modification that would require separate regulatory consideration. Regulatory review and local implementation evaluation should proceed together where relevant.
Local validation does not need to become a research study every time
There is a practical risk at the other extreme: making local validation so complicated that responsible evaluation becomes unrealistic. Not every AI implementation requires a large prospective clinical trial, academic publication or formal research study.
The depth of evaluation should reflect the potential severity of harm if the AI is wrong, how directly its output influences care, the strength and relevance of existing evidence, differences between the original evaluation environment and the local environment, the degree of automation, the reversibility of decisions and the organization’s ability to detect problems once the system is deployed.
A lower-risk tool that structures documentation for clinician review may require a very different level of evaluation from an AI system that identifies a time-critical diagnosis or directly controls treatment-related equipment. The objective is not maximum validation. It is sufficient validation for the risk, intended use and uncertainty that remain.
A practical Local Validation Gate
Before routine use, a healthcare organization can apply a Local Validation Gate across several connected domains.
Intended-use fit: Is the proposed local use consistent with the system’s defined purpose, target population, intended users and conditions of use?
Evidence transferability: Are the populations, disease spectrum, data sources, equipment and clinical environments represented in existing evidence sufficiently similar to the local setting?
Technical and data integrity: Are the correct inputs reaching the system reliably, and are outputs delivered accurately and at the appropriate point in the workflow?
Clinical performance: Do locally relevant performance measures meet predefined and clinically meaningful acceptance criteria?
Failure and subgroup analysis: Are important error patterns, edge cases and clinically relevant performance differences understood well enough to manage?
Human-AI and workflow fit: Can intended users understand and act on outputs appropriately under normal working conditions, with realistic human oversight?
Governance readiness: Have applicable AI, medical-device, personal-data, cybersecurity, accountability and documentation requirements been addressed, and is an appropriate monitoring plan ready for routine use?
The Local Validation Gate is an organizational patient-safety and governance framework proposed for practical implementation. It is not a statutory checklist created by Vietnamese law. Its purpose is to prevent one strong result, such as a high AUROC, a favorable vendor study or positive clinician feedback, from being treated as sufficient evidence for a decision that actually depends on several interconnected conditions.
The validation decision should not be simply “pass” or “fail”
Local evidence often supports a more nuanced decision than a binary pass or fail. Proceed to routine use may be appropriate when performance, workflow, technical integration and governance are sufficiently supported for the proposed use. Proceed with restrictions may be reasonable where evidence is acceptable only for a defined population, site, device, workflow or group of trained users and enhanced monitoring is needed.
Remediate and revalidate may be appropriate when the underlying technology remains promising but problems with integration, data quality, configuration, training or workflow need to be corrected. Do not deploy may be appropriate when performance is inadequate, clinically important uncertainty remains too high, failure modes cannot be controlled or the system does not provide sufficient value to justify its risk and operational burden.
A decision not to deploy is not necessarily a failed AI project. Identifying an unsafe, ineffective or unsuitable implementation before routine exposure can be one of the most valuable outcomes of responsible validation.
Validation should create a baseline for monitoring, not end evaluation
The most useful output of local validation is not only a go-live decision; it is also a baseline. Once AI enters routine practice, healthcare organizations need to know what acceptable performance looked like at implementation so that meaningful deterioration can later be recognized.
The validation record should therefore document the model or software version, intended use, patient population, data and technical environment, relevant equipment, performance measures, subgroup findings, known failure modes, user configuration, workflow, acceptance criteria and unresolved limitations. That information becomes particularly important when something changes.
A model update, new device, different laboratory method, altered workflow, new patient population, expansion to another site or change in the level of clinical reliance may weaken the assumptions on which the original validation was based. Decree No. 142 requires the deployer to coordinate with the provider to review and, where necessary, reclassify the system when deployment, modification, integration or a change in function or intended purpose creates new or higher risks. For systems classified as high-risk, a significant change can also require a new conformity assessment under Article 13 of the AI Law, subject to any applicable transitional provisions.[1-3]
Not every software update requires the entire local validation process to begin again. But a material change should always trigger a basic question: Does the evidence we relied on before still apply?
Revalidation should be triggered by change, not by calendar alone
Periodic review can be useful, but the calendar should not be the only trigger. Healthcare organizations should consider additional evaluation when a material software or model update occurs; the intended purpose, population or clinical workflow changes; new devices or data sources are introduced; deployment expands to a materially different site; routine monitoring identifies performance deterioration; clinically relevant subgroup differences emerge; a significant safety incident occurs; or the vendor identifies a new limitation or failure mode.
This reflects the broader lifecycle approach increasingly adopted internationally. IMDRF’s GMLP principles emphasize monitoring deployed models and managing risks associated with retraining or model change, while the FDA, Health Canada and MHRA transparency principles connect local site-specific acceptance testing or validation with ongoing performance monitoring, transparent reporting and change management.[8,10]
Local validation should therefore be treated as a renewable body of evidence, not a certificate that remains valid indefinitely.
What local validation means for healthcare organizations in Viet Nam
Clinical AI adoption in Viet Nam will increasingly involve technologies developed elsewhere and introduced into healthcare organizations with different patient populations, infrastructure, workflows and levels of digital maturity. That makes local validation particularly valuable because it creates a disciplined bridge between “this technology has evidence” and “this technology has enough relevant evidence for us to use it responsibly here.”
The process should not reject international evidence or unnecessarily repeat work that has already been done. Strong external validation should reduce local uncertainty. Regulatory assessments, peer-reviewed studies, vendor technical evidence and experience from comparable healthcare organizations can all contribute. Viet Nam’s Decree No. 142 itself recognizes that valid assessment results obtained under relevant specialized legal frameworks can, within their assessed scope, be used to demonstrate corresponding requirements rather than requiring unnecessary duplication.[2]
But external evidence does not completely remove the healthcare organization’s need to understand what happens when the technology meets its own patients, data, equipment, clinicians and workflow.
WHO/Europe’s September 2026 Knowledge Community report identified validation as one of five priority areas raised by participants for responsible AI adoption in health, together with governance, data, workforce capacity and participation by patients, communities and frontline professionals.[11] The report reflects the structured views of Knowledge Community participants and should not be interpreted as a binding WHO regulatory standard.
For healthcare leaders, the practical message is straightforward: do not ask only whether an AI system works. Ask whether it works well enough for your patients, with your data, your equipment, your clinicians and your workflow, and whether you know how you will recognize if that stops being true.
That is the purpose of local validation. It is not to demand certainty before innovation; healthcare rarely offers certainty. It is to reduce important uncertainty before clinicians and patients are asked to depend on a technology.
In responsible clinical AI, evidence should travel with the system. Before routine use, healthcare organizations should still confirm that the evidence has arrived intact.
Professional education notice
This article is intended for professional education and knowledge exchange. It does not constitute individualized legal, regulatory, clinical, medical-device, statistical, cybersecurity, personal-data or conformity-assessment advice.
The term local validation in this article refers to an organizational approach to assessing locally relevant performance, safety, technical compatibility, human factors and workflow fit. It is not a statutory term describing a single mandatory validation procedure applicable to all clinical AI systems under Vietnamese law.
The Local Validation Gate, staged-validation approach and decision outcomes described above are practical governance recommendations. They are not statutory requirements unless a particular obligation is otherwise imposed by applicable legislation, regulation, technical regulation, contractual arrangement or specialized regulatory framework.
Local validation does not replace any required conformity assessment, medical-device procedure, regulatory authorization, ethical review, personal-data requirement or other applicable legal obligation. Where retrospective, prospective or limited live evaluation is undertaken, organizations should separately determine whether the activity constitutes routine implementation, quality improvement, research, an organizational pilot or participation in the formal controlled-testing mechanism under Viet Nam’s AI Law and Decree No. 142/2026/NĐ-CP, as applicable.
References
National Assembly of Viet Nam. Law No. 134/2025/QH15 on Artificial Intelligence. Adopted 10 December 2025; effective 1 March 2026.
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. 30 April 2026; effective 1 May 2026.
Prime Minister of Viet Nam. Decision No. 33/2026/QĐ-TTg Promulgating the List of High-Risk Artificial Intelligence Systems. 30 June 2026; effective 15 August 2026.
National Assembly of Viet Nam. Law No. 91/2025/QH15 on Personal Data Protection. Adopted 26 June 2025; effective 1 January 2026.
Government of Viet Nam. Decree No. 356/2025/NĐ-CP Detailing a Number of Articles and Measures for Implementation of the Law on Personal Data Protection. 31 December 2025; effective 1 January 2026.
Ministry of Health of Viet Nam. Consolidated Document No. 08/VBHN-BYT on medical-device management. 6 March 2026, consolidating the current framework based on Decree No. 98/2021/NĐ-CP and its amendments.
Ministry of Health of Viet Nam. Circular No. 24/2026/TT-BYT on determining risk levels and management measures for products and goods that are medical devices and amending certain provisions of Circular No. 05/2022/TT-BYT. 30 June 2026; effective 1 July 2026.
International Medical Device Regulators Forum. Good Machine Learning Practice for Medical Device Development: Guiding Principles. IMDRF/AIML WG/N88 FINAL:2025. 29 January 2025.
International Medical Device Regulators Forum. Software as a Medical Device (SaMD): Clinical Evaluation. IMDRF/SaMD WG/N41FINAL:2017. 21 September 2017.
U.S. Food and Drug Administration, Health Canada and UK Medicines and Healthcare products Regulatory Agency. Transparency for Machine Learning-Enabled Medical Devices: Guiding Principles. June 2024.
World Health Organization Regional Office for Europe. Report of the Knowledge Community on Responsible Artificial Intelligence in Health. 1 September 2026. WHO/EURO:2026-13381-53155-83077.