Clinical AI Change Control in Viet Nam: How Healthcare Organizations Should Govern Updates, Material Changes and Revalidation
PRACTICAL FRAMEWORKS & TOOLS
Clinical AI Change Control in Viet Nam: How Healthcare Organizations Should Govern Updates, Material Changes and Revalidation
PRACTICAL FRAMEWORKS & TOOLS
Last reviewed: 2 October 2026
A healthcare organization may approve a clinical AI system after reviewing the evidence, completing local validation, training staff and establishing monitoring. Six months later, however, the system may no longer be exactly the system that was originally approved.
The provider may retrain the model, introduce new data, change a decision threshold, redesign the interface or add functionality. The technology may move to a different cloud environment or connect to a new data source. The healthcare organization itself may expand the AI to another department, another hospital site, a different patient population or a workflow in which clinicians rely on its output more heavily than before.
Some of these changes are routine. Others can alter performance, patient safety, human oversight, data processing or regulatory status. The practical question is therefore not simply “Has the AI been updated?” It is “What changed, could that change matter, what evidence do we need before relying on the changed system, and who decides whether it is safe to continue?”
That is the purpose of clinical AI change control.
In Viet Nam, change control now has a clear regulatory dimension. The 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] Providers must classify AI systems before use, while deployers must coordinate with providers to review and, where necessary, reclassify systems when deployment, modification, integration or changes in function or intended purpose create new or higher risks. High-risk AI is subject to conformity assessment, and a significant change affecting the original conformity-assessment result can require reassessment.[1,2]
At the same time, Vietnamese law does not treat every software update as regulatory reinvention. Decree No. 142 expressly excludes routine data updates, ordinary technical corrections, performance optimization or version upgrades from the significant-change concept when they do not alter compliance with the applicable high-risk requirements. It similarly distinguishes routine changes that do not alter the nature of risk from changes that require reclassification.[2]
Healthcare organizations therefore need a proportionate process that avoids two extremes: treating every minor patch as a new AI implementation, or allowing clinically meaningful change to enter routine practice without review.
Monitoring and change control answer different questions
Monitoring and change control are closely connected, but they are not the same process. Monitoring asks whether performance, safety, drift, incidents or user behavior are changing after go-live. Change control begins when the organization knows—or should know—that something about the system or its deployment is changing.
Monitoring may discover an unplanned deterioration. Change control governs a known model update, configuration change, workflow modification, new integration, deployment to another site or another identifiable change. A mature lifecycle therefore looks more like:
monitor → identify change or need for change → assess impact → approve or reject → validate → deploy → monitor again
Good post-go-live monitoring does not remove the need for controlled change.
“Material change” and statutory “significant change” are not the same thing
This distinction is particularly important in Viet Nam.
In this article, material change is an organizational governance term. It means a change important enough to justify structured review because it could affect clinical performance, patient safety, workflow, data, users, human oversight or accountability.
Vietnamese AI legislation uses significant change in a more specific regulatory sense. For high-risk AI, Decree No. 142 requires conformity reassessment when a significant change affects the original assessment result. Examples include changes to the main function, intended purpose or scope that create new risk or change the assessed level of risk; changes to system architecture, the AI model or major technical configuration that may affect accuracy, reliability, safety or controllability; significant changes to major data sources, input-data types or data-processing methods; integration into another system or operating environment that changes previously assessed conditions; and other changes materially affecting compliance with the high-risk requirements.[2]
Risk reclassification is related but distinct. Where local deployment, modification, integration or changes in function or intended purpose create new or higher risk, the deployer must coordinate with the provider to review the classification and address any resulting higher-risk requirements.[2]
A healthcare organization should therefore not call every internally important change a statutory “significant change.” Nor should it assume that a change is legally insignificant simply because a provider describes the release as minor. Internal change-impact assessment and regulatory assessment need to work together.
Start with an approved baseline
Change cannot be governed reliably if the organization cannot describe what was originally approved.
For each clinical AI system, the organization should be able to identify the approved software and, where relevant, model version; intended use; target population; deployment sites; important configuration settings; data sources; interfaces; degree of automation; human-oversight arrangements; baseline performance; known limitations; local-validation findings; approved workflow; and relevant regulatory status.
That information should connect to the organization’s AI inventory rather than sit in isolated departmental files.
The core question is:
What is different from the version, configuration and use that we originally approved?
Without a reliable baseline, the organization may know that an update occurred without knowing whether the assumptions supporting the original approval still hold.
Change can originate from the provider or from the healthcare organization
Change control should not focus only on provider-side model updates.
A provider may retrain the model, alter algorithms or thresholds, introduce new training data, change preprocessing, modify the interface, replace technical components, change hosting arrangements or add new features.
But the healthcare organization can also change the system without changing the model. It may connect the AI to a new information system, alter data mappings, introduce different equipment, expand access to new users, move the system to another site, broaden the patient population or redesign the workflow.
These changes can matter just as much.
For example, an AI tool that originally displays an advisory result may later be connected to a workflow in which its output automatically determines queue priority. The model has not changed, but its influence has. The same imaging AI moved to another hospital may encounter different scanners, acquisition protocols, prevalence and clinical workflows. A prediction model connected to a new laboratory platform may receive inputs whose definitions or units differ from those originally validated.
Clinical change control must therefore govern the deployed socio-technical system, not only the mathematical model.
Build a proportionate change pathway before the first update arrives
Healthcare organizations should decide in advance how changes enter governance rather than inventing the process after an important update occurs.
The practical rule should be that a change with plausible clinical, technical, data, human-factor or regulatory impact does not enter unrestricted routine use until it has been identified, assessed and approved at a level proportionate to its risk.
Change information may come from the provider, IT, clinical departments, quality and patient safety, cybersecurity, privacy teams, the AI governance function or routine monitoring. Staff need a clear route for escalating suspected material changes.
Contracting also matters. Where appropriate, agreements should require advance or timely notification of changes that could affect intended use, model or software version, performance, data requirements, thresholds, integrations, cybersecurity, hosting, important subcontractors, transparency information or regulatory status. A healthcare organization should not discover a clinically meaningful update only after frontline users begin experiencing it.
Not every change deserves the same review. An organization may internally distinguish routine changes, review-required changes, material clinical or governance changes, and changes that may meet statutory criteria for reclassification or significant change. These are internal governance categories, not classifications created by Vietnamese law.
The purpose is proportionality.
Assess impact before deciding what to revalidate
Once a meaningful change is identified, the organization should determine what the change could affect.
The review should consider clinical impact: could diagnosis, triage, prediction, treatment or another patient-care decision change? It should consider performance impact: could accuracy, calibration, sensitivity, specificity, subgroup performance, uncertainty or failure modes change?
Data impact may include new data sources, altered mappings, preprocessing, missing-data handling or transfer pathways. Human-factor impact may arise because an interface changes, alerts are presented differently, automation increases or a different group of clinicians begins using the system.
Workflow impact matters when the AI reaches different users or triggers different downstream actions. The review should also consider cybersecurity, infrastructure, privacy and regulatory consequences. A new API, new cloud environment, new processing location, new subcontractor or new use of patient information can create risks that were not part of the original approval.
Only after understanding these effects should the organization decide what validation is needed.
Revalidation should target the assumptions that changed
A change does not automatically require repeating the entire original local-validation process.
If a user-interface modification does not change model input, output or clinical interpretation, usability testing may be more relevant than repeating a full clinical-performance study. If data mapping changes, technical verification and targeted performance testing may be needed. If the model itself is retrained, calibration, subgroup performance, error patterns and clinical performance may deserve renewed evaluation.
If the AI expands to a new population, the organization should ask whether the original evidence remains transportable to that population. If it moves to a new hospital site, local technical acceptance and workflow validation may matter even when the underlying algorithm is unchanged.
The key question is:
Which assumptions underlying the original approval have changed?
Revalidation should focus on those assumptions.
In this article, revalidation means an organizational patient-safety and implementation process used to determine whether the evidence supporting local use remains adequate after change. It is not the same as statutory conformity reassessment under the AI Law and Decree No. 142. The two processes can overlap, but they answer different questions.
High-risk AI needs a regulatory escalation pathway
For legally classified high-risk AI, change control also requires regulatory review.
Article 13 of the AI Law requires high-risk AI systems to undergo conformity assessment before use and when significant changes occur. The assessment confirms compliance with the high-risk requirements in Article 14.[1]
Decree No. 142 operationalizes that framework. The provider carries out the applicable conformity assessment and must reassess conformity when a significant change affects the original result. Valid assessment results obtained under specialized legislation, technical regulations or product-quality law can be used to demonstrate corresponding requirements within the scope already assessed, while requirements not previously covered still need to be addressed.[2]
Healthcare organizations therefore need a regulatory escalation route so that an important clinical change is not treated solely as an IT release-management issue.
Medical-device obligations remain a separate layer
Some clinical AI systems are also, or form part of, medical devices. In those cases, AI change governance does not replace the applicable medical-device framework.
Viet Nam’s medical-device management framework continues to be based on Decree No. 98/2021/NĐ-CP as amended, reflected in Consolidated Document No. 08/VBHN-BYT dated 6 March 2026. Circular No. 24/2026/TT-BYT, issued on 30 June 2026 and effective from 1 July 2026, addresses medical-device risk classification and management measures and amends parts of the implementing framework.[3,4]
Where AI is or forms part of a medical device, healthcare organizations should separately determine whether a proposed change affects its declared or authorized intended purpose, configuration, performance or other regulated characteristics and whether the manufacturer, registration holder or another responsible party needs to address additional medical-device requirements.
Internal AI approval cannot legitimize a change that is inconsistent with the applicable medical-device framework.
Planned change is easier to govern than surprise change
One useful international concept is the Predetermined Change Control Plan, or PCCP.
FDA’s current final guidance, dated August 2025, recommends that a PCCP for an AI-enabled device software function describe planned modifications, the methodology for developing, validating and implementing those modifications, and an assessment of their impact. Within the U.S. regulatory framework, FDA reviews a PCCP as part of the device marketing submission so that specified future modifications may be implemented under the authorized plan without requiring a separate marketing submission for each individual change.[5]
IMDRF subsequently published N90 FINAL:2026, Essential Principles and Content of Predetermined Change Control Plans, on 6 August 2026. N90 describes three interconnected PCCP elements: a Description of Changes, a Change Plan including verification, validation and predefined acceptance criteria, and an Impact Assessment considering benefits, risks and mitigation. It also emphasizes risk-based control, transparency, traceability and total-product-lifecycle thinking.[6]
These documents do not establish a PCCP regulatory pathway in Viet Nam. FDA PCCPs operate within U.S. device regulation, while IMDRF recognizes that implementation varies by jurisdiction.
The broader implementation lesson is nevertheless useful:
When future changes can reasonably be anticipated, define the boundaries, evidence, validation, acceptance criteria, communication and deployment process before those changes occur.
IMDRF is also developing N93, Technical Framework for Artificial Intelligence Life Cycle Management. Public consultation closed on 10 July 2026, and as of 2 October 2026 IMDRF still describes N93 as A Proposed Document, not a final standard or guidance.[7]
Change control needs to look beyond the model
Some of the most important changes occur around the model rather than inside it.
Cloud-based AI illustrates the problem. A provider may update the underlying model, retrieval system, safety configuration or orchestration layer centrally while the hospital continues to see the same product name and interface. For clinically important applications, “the service is always up to date” is not sufficient governance information. Organizations should understand what version information is available, how significant changes are communicated and whether previous behavior can be reconstructed if an incident needs investigation.
Human oversight can also change without any model update. A recommendation once treated as optional may become embedded into workflow automation. A system initially used by experienced specialists may later be expanded to a wider user group. Those changes can alter reliance, override behavior, competency requirements and patient risk.
Data, privacy and cybersecurity may change as well. A new version may require additional inputs. A new integration may expose information to another system. Cloud migration may introduce a different processing environment. Retraining may use local patient data in ways that were not part of the initial deployment. New APIs, components or third parties may create additional attack surfaces.
The same applies to workforce and transparency. A changed output may require different training. A new interface may introduce new failure modes. Increased automation or a newly identified limitation may require updates to policies, user instructions or patient-facing information.
A software release is therefore not complete merely because the new code runs successfully. The surrounding clinical, human and governance system must still remain valid.
Controlled deployment needs fallback, enhanced monitoring and traceability
Before a material change goes live, the organization should know what it will do if the changed system behaves unexpectedly.
Where technically possible, it should know whether the previous version can be restored and who has authority to initiate rollback. Where rollback is impossible, as may occur with some cloud services, there should still be an operational fallback, such as disabling the AI function, reverting to a non-AI workflow or restricting use while the problem is investigated.
Emergency changes also need governance. A serious vulnerability, safety incident or defective model may require immediate suspension, patching or replacement. Decision rights should therefore be defined in advance: who can restrict or suspend use, who can authorize urgent technical action, what minimum testing is required before restoration and when clinical leadership, quality, IT, cybersecurity, privacy or the provider must be involved.
Good emergency governance does not make urgent action slower. It makes safe action faster because authority has already been established.
Important changes should then enter a period of enhanced monitoring. Performance indicators, incidents, false-positive and false-negative patterns, user overrides, complaints, latency, workflow disruption and relevant subgroup performance may need closer observation until there is reasonable assurance that the change is behaving as expected.
Traceability should continue throughout this process. The organization should be able to reconstruct what changed, why it changed, who initiated it, the previous and new versions where available, the impact assessment, regulatory review, validation performed, acceptance criteria, approval decision, deployment date, user communication or training, monitoring plan and any subsequent rollback.
Months later, someone should still be able to answer:
Why did we approve this version, and what evidence did we rely on?
A practical Clinical AI Change Control Gate
Before a material change enters routine clinical use, a healthcare organization can apply a simple Clinical AI Change Control Gate:
Change definition: Do we know exactly what changed compared with the approved baseline?
Change source: Is the change provider-driven, organization-driven, automatic, manual or caused by a new deployment environment?
Clinical impact: Could the change alter patient care, clinical decisions, workflow or degree of automation?
Performance and evidence: Could performance, calibration, subgroup behavior, uncertainty, limitations or failure modes change?
Data and technical impact: Have inputs, data sources, preprocessing, interfaces, infrastructure, security conditions or third-party dependencies changed?
Human oversight: Does the change affect who uses the system, how outputs are interpreted, override mechanisms, reliance or required competency?
Regulatory impact: Could the change trigger AI risk reclassification, high-risk conformity reassessment, medical-device obligations or another regulatory review?
Revalidation: Which assumptions supporting the previous approval have changed, and what targeted technical, usability or clinical validation is needed?
Communication: Do users, patients, policies, instructions, training materials or transparency information need to be updated?
Deployment control: Are approval authority, implementation timing, downtime arrangements, fallback and rollback clear?
Post-change monitoring: Is enhanced monitoring defined for the period after deployment?
Traceability: Is the change, supporting evidence, governance decision and resulting version recorded in the AI inventory and change history?
This Gate is a practical organizational governance framework. It is not a statutory checklist under Vietnamese law.
What this means for healthcare organizations in Viet Nam
Healthcare organizations should not assume that an AI system remains the system they originally approved simply because the product name has not changed.
Governance needs to follow the technology as it evolves. That starts with a stable baseline, a reliable AI inventory and clear expectations with providers. When a change occurs, the organization should understand what changed, assess whether clinical risk or regulatory status may be affected, validate what needs to be validated, prepare users, control deployment and monitor the changed system closely afterward.
At the same time, change control should remain proportionate. Vietnamese law itself distinguishes meaningful risk-changing modifications from routine changes that do not alter the nature of risk or high-risk compliance. Responsible organizational governance should do the same.[2]
Healthcare organizations should resist two extremes: freezing AI because change feels risky, and allowing continuous change simply because software is expected to evolve. Both can create patient-safety problems.
Responsible clinical AI requires controlled evolution.
For healthcare leaders, the practical question is therefore not simply “Did the provider update the AI?” It is “Is the system we are using today still supported by the evidence, controls and assumptions on which we originally decided it was safe to use?”
If that answer changes, governance should change with it.
That is what clinical AI change control is for.
Professional education notice
This article is intended for professional education and knowledge exchange. It does not constitute individualized legal, regulatory, clinical, medical-device, cybersecurity, personal-data, statistical or conformity-assessment advice.
The term material change, the internal change categories and the Clinical AI Change Control Gate described in this article are practical organizational governance concepts. They are not statutory definitions under Vietnamese law. In particular, organizational material change should not be confused with significant change for purposes of AI risk reclassification or high-risk conformity reassessment under the Law on Artificial Intelligence and Decree No. 142/2026/NĐ-CP.
Revalidation in this article refers to an organizational process used to determine whether evidence supporting local safe use remains adequate after change. It does not replace statutory conformity reassessment, medical-device procedures or other regulatory requirements where those apply.
FDA’s PCCP framework and IMDRF N90 are international technical references and do not establish Vietnamese regulatory requirements. IMDRF N93 remained a Proposed Document as of 2 October 2026.
Healthcare organizations should separately assess applicable obligations under AI legislation, medical-device regulation, personal-data protection, cybersecurity, professional-practice requirements and other specialized legislation.
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. 30 April 2026; effective 1 May 2026.
[3] Ministry of Health of Viet Nam. Consolidated Document No. 08/VBHN-BYT on medical-device management. 6 March 2026.
[4] 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.
[5] U.S. Food and Drug Administration. Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions. Final Guidance, August 2025.
[6] International Medical Device Regulators Forum. Essential Principles and Content of Predetermined Change Control Plans. IMDRF/SaMD WG/N90 FINAL:2026. 6 August 2026.
[7] International Medical Device Regulators Forum. Technical Framework for Artificial Intelligence Life Cycle Management. IMDRF/AIML WG/N93 Proposed Document. Public consultation closed 10 July 2026; as of 2 October 2026, IMDRF continued to list the document as proposed.