Building a Clinical AI Safety Case in Viet Nam: A Practical Framework for Linking Hazards, Controls, Evidence and Residual Risk
PRACTICAL FRAMEWORKS & TOOLS
Building a Clinical AI Safety Case in Viet Nam: A Practical Framework for Linking Hazards, Controls, Evidence and Residual Risk
PRACTICAL FRAMEWORK & TOOL
Last reviewed: 3 October 2026
A healthcare organization can have an AI policy, a risk register, a validation report, a vendor contract, a training program and months of monitoring data, and still struggle to answer a simple question:
Why do we believe this AI system is safe enough to use here, for these patients, in this workflow, under these conditions?
A list of controls does not answer that question. Neither does a high model-performance score, regulatory status, a successful pilot or a folder full of technical documentation. Each can provide useful evidence, but the organization still needs to connect those pieces into a coherent argument about safety.
That is the purpose of a clinical AI safety case.
For this article, a clinical AI safety case means a structured organizational argument explaining why the residual clinical risks associated with a defined AI deployment are considered acceptable, supported by evidence showing that relevant hazards have been identified, appropriate controls have been implemented and those controls work sufficiently well in the actual clinical environment.
The concept has a long history in safety-critical systems and health IT. In England, DCB0160 establishes clinical-risk-management requirements for health and care organizations responsible for deploying, using, maintaining or decommissioning health IT systems. Its current specification requires organizations within scope to maintain a hazard log and Clinical Safety Case, while NHS England's 2026 clinical-safety training describes the Clinical Safety Case Report as an assurance argument supported by evidence and emphasizes traceability from hazards to controls to test evidence. DCB0160 remains the current published standard, although NHS England is reviewing DCB0129 and DCB0160 to reflect changes including AI and evolving clinical workflows.
For Viet Nam, however, an important distinction should be clear from the beginning: “clinical AI safety case” is not currently the name of a statutory document required by Viet Nam's Law on Artificial Intelligence. It is a practical assurance method that healthcare organizations can use to bring risk management, evidence, governance and patient safety into one coherent decision.
The core logic is straightforward:
clinical context → hazards → controls → evidence → residual risk → accountable decision → continuing monitoring.
The value lies in making every link explicit.
A safety case is an argument, not a declaration that AI is “safe”
No credible safety case should claim that an AI system has zero risk. Clinical care already contains uncertainty, and AI can introduce additional uncertainty through model error, data quality, changing patient populations, workflow interactions, human overreliance, cybersecurity events, software changes, downtime and unexpected interactions between system components.
The relevant question is therefore not, “Can we prove that nothing will ever go wrong?” It is whether the organization has identified reasonably foreseeable hazards, reduced them where practicable, tested the controls intended to reduce them, understood what risk remains and decided explicitly whether that remaining risk is acceptable for the defined clinical use.
NIST's AI Risk Management Framework uses similar logic. MEASURE 2.6 calls for regular evaluation of AI safety risks and states that the residual negative risk of the system should not exceed the organization's risk tolerance. NIST also treats AI risk as contextual: safety needs to be evaluated in relation to the conditions in which the system will actually be used rather than through a single universal threshold.
This matters in healthcare because the same model can have very different safety implications in different deployments. A false negative in a low-consequence administrative workflow is not equivalent to a false negative in a workflow that influences urgent clinical prioritization. The model may be the same; the clinical consequences are not.
A safety case is therefore always about a particular system, used for a particular purpose, in a particular operating environment.
A risk register is necessary, but it is not a safety case
An AI inventory and risk register provide an important foundation. They can record that a hazard exists, estimate its likelihood and consequence, identify controls, assign owners and support prioritization.
A safety case asks the next question:
What evidence gives us confidence that those controls actually reduce the risk in this workflow?
Consider an AI system used to help prioritize clinical cases. One hazard might be that an urgent patient is assigned an inappropriately low priority. Possible causes could include atypical presentation, incomplete input data, distribution shift, an integration problem or inappropriate reliance on the AI output, with delayed clinical assessment or treatment as a potential consequence.
A risk register might identify “clinical review remains mandatory” as a control. That is useful, but the statement itself is not assurance. The organization still needs to know whether clinical review genuinely occurs, whether staff understand that responsibility, whether the interface makes disagreement possible, whether workload allows meaningful review and whether testing shows that urgent cases are not systematically delayed.
The safety case therefore keeps the complete chain visible:
hazard → cause or failure scenario → control → evidence that the control exists and works → residual risk.
It also disciplines how evidence is used. A vendor's retrospective performance study may support a claim about model discrimination in a particular dataset, but it does not automatically demonstrate performance in Vietnamese patients. A cybersecurity test may support a security claim but does not show that clinicians can identify an incorrect AI recommendation. A training attendance record proves attendance, not competence. A policy requiring human review demonstrates an organizational expectation, but it does not show that meaningful review is feasible under real clinical workload.
The distinction is fundamental:
a control describes what should reduce risk; evidence shows whether that control has actually been implemented and whether it performs as intended.
Evidence may come from analysis, observation, testing, simulation, audit, local validation or operational monitoring. NHS England's current clinical-safety training similarly emphasizes traceability between hazards, controls and test evidence rather than treating documentation volume as proof of safety.
The practical implication is simple: evidence should be collected because it supports a safety claim, not merely because it is available.
Start with the clinical workflow, not with the model
A weak safety argument begins with technology:
The model has an AUROC of 0.94.
A stronger one begins with a clinical claim:
This AI-supported workflow can be used for the defined purpose in this healthcare organization with residual clinical risk remaining within the organization's agreed tolerance, provided that the specified controls continue to operate effectively.
That claim immediately creates useful questions. What is the intended use? Who uses the AI? Which patient populations are included or excluded? What decision can the output influence? Is the system advisory, prioritizing, drafting, recommending or acting? What happens if it is wrong? What information systems feed it data? Who can override it? What fallback exists? Which product, model and version are covered?
These boundaries matter because assurance becomes weak when the claim is vague. “AI radiology tool” is not an adequate safety-case scope. A useful safety case identifies the relevant product and version, clinical task, sites, patient population, workflow position, users, integrations, human-review requirements and important exclusions. If those conditions change materially, the original assurance argument may no longer remain valid.
Hazard identification should then follow the actual clinical workflow. A generic AI-risk checklist can help prompt discussion, but patient harm occurs through real care processes. A simplified pathway might be:
patient/data acquisition → AI input → model processing → output presentation → human interpretation → clinical decision → downstream action.
Each transition creates possible failure modes. Input data may be incomplete or linked to the wrong patient. The model may be wrong. The interface may show the correct result in the wrong context. A clinician may misunderstand a confidence value. An alert may arrive too late. An automated action may occur before meaningful review. A model update may change behavior, or the fallback process may fail when the system becomes unavailable.
A 2025 deployment safety-case study involving AI-assisted prostate-cancer diagnosis followed this logic: researchers mapped the clinical workflow, performed hazard and risk analysis in the deployment context and then constructed a safety case for deployment and continuing monitoring. The work highlights why hazards can emerge from the way a regulatorily approved product interacts with a clinical pathway and other local systems rather than from the model alone.
The lesson is broader than the specific AI examined in that study:
hazard identification should follow the clinical work, not stop at the algorithm.
That is also why multidisciplinary input matters. Clinicians, quality and patient-safety teams, IT, cybersecurity, biomedical or medical-device functions, frontline users and vendors can each see failure pathways that others may miss.
Controls need evidence, especially when the control is a human
Once hazards have been identified, controls should address the mechanisms through which harm might occur. Some controls are technical: input validation, fail-safe behavior, access control, interface safeguards, version management or integration testing. Others are clinical or operational: independent review, escalation pathways, exclusion criteria, fallback procedures or limits on automation. Organizational controls can include training, competency requirements, incident reporting, vendor-change notification and post-deployment monitoring.
A single hazard may need several controls because no individual safeguard is sufficiently reliable. An incorrect AI-generated recommendation, for example, might be mitigated through local validation, appropriate interface design, clear limitations, meaningful human review, easy override, exclusion criteria and continuing monitoring. Together, these create defence in depth.
Human oversight deserves particular attention because it is frequently listed as a control without evidence that it actually works. If the safety argument depends on a clinician identifying an AI error, the organization needs to ask whether the relevant information is visible, whether the user has enough time to review it, whether disagreement is operationally easy and whether training includes realistic failure modes.
Evidence for human oversight might include usability studies, simulation with deliberately incorrect AI outputs, workflow observation, competency assessment, override testing, review latency, patterns of AI–human disagreement, near-miss review or incident data.
This is also relevant to Viet Nam's AI framework. Decree No. 142/2026/NĐ-CP imposes detailed risk-management requirements on high-risk AI systems. Providers must establish and maintain risk-management systems, while deployers must manage risk during actual operation, monitor for errors, risks or incidents and establish and maintain human-oversight and intervention mechanisms.
The regulatory framework establishes that oversight matters. The safety case asks the operational question:
Does our oversight actually work?
Local validation is another important form of evidence, but it should only support the claims it was designed to test. A validation study may demonstrate acceptable performance in the local population, identify subgroup differences or expose workflow and data-quality problems. It may say little about cybersecurity, downtime, automation bias, incident response or behavior after a vendor update.
A credible safety case therefore draws on several evidence streams where necessary: scientific literature, vendor technical evidence, regulatory documentation, local validation, integration testing, cybersecurity testing, human-factors evaluation, training and competency evidence, workflow simulation, downtime testing, incident exercises and post-go-live monitoring.
The objective is not to collect everything. It is to ensure that each material safety claim has appropriate evidence behind it, and each important piece of safety evidence has a clear claim that it supports.
Residual clinical risk is not the same as statutory AI risk classification
The word “risk” can easily become confusing because Viet Nam's AI framework also uses formal statutory risk classification.
A safety case uses residual clinical risk differently. It means the clinical risk that remains after specified controls have been implemented.
An AI system may not be classified as legally high-risk under Viet Nam's current statutory framework and still create significant clinical risk within a particular hospital workflow. Conversely, legal classification as high-risk does not tell a healthcare organization whether all hazards in its own deployment have been adequately controlled.
Decision No. 33/2026/QĐ-TTg, effective from 15 August 2026, currently contains two healthcare entries in the statutory high-risk list. Both concern specified AI-assisted surgical or robotic systems under defined conditions.
That relatively narrow current list does not mean that other forms of clinical AI require little safety governance. Diagnostic-support systems, deterioration models, ambient scribes and other AI applications may create meaningful patient-safety hazards even when they are not currently included in the statutory high-risk list.
The safety-case question is therefore different from the legal-classification question:
After our actual controls are applied, what clinical risk remains, and are we prepared to accept it?
That decision also needs accountability. Residual risk does not become acceptable simply because a project team has finished testing. The healthcare organization should define its risk-acceptance criteria and who has authority to accept remaining risk for the particular deployment.
For health and care organizations within scope in England, DCB0160 provides one established model. Its specification requires the organization to define risk-acceptability criteria, maintain a hazard log and develop and maintain a Clinical Safety Case for the health IT system. DCB0160 is mandatory in its applicable English context under the Health and Social Care Act 2012. The published 2018 Update remains the current release as of the review date, while NHS England is conducting a formal review of DCB0129 and DCB0160.
DCB0160 is not applicable law in Viet Nam. Its governance logic is nevertheless useful: risk acceptance should be explicit rather than implied.
Depending on the AI and its potential clinical consequence, a Vietnamese healthcare organization's acceptance process may involve the accountable clinical service, quality and patient safety, AI governance, IT or cybersecurity and senior leadership. The decision should record not only that the AI was “approved,” but what material risks remain, why they are considered acceptable and under what conditions continued use remains acceptable.
Viet Nam's AI framework supports this assurance logic, but does not require a document called a safety case
Viet Nam's Law on Artificial Intelligence No. 134/2025/QH15 was adopted on 10 December 2025 and has been effective since 1 March 2026. Decree No. 142/2026/NĐ-CP, issued on 30 April 2026 and effective from 1 May 2026, provides the detailed implementation framework, including risk classification, conformity assessment and management of high-risk AI systems.
For high-risk AI systems, providers must establish and maintain risk-management arrangements appropriate to intended use, deployment scope and risk. Deployers have operational responsibilities that include use within defined conditions, monitoring for deviations, risk and incidents, maintaining human oversight and intervention, and applying risk-control measures within their authority.
High-risk AI is also subject to conformity assessment. During use, providers must reassess conformity when specified significant changes affect the original assessment, including material changes to main functions or intended use, AI models or principal technical configuration, key data inputs or processing, or integration into new systems or operating environments.
An organizational safety case can help bring together evidence relevant to those responsibilities. It does not replace statutory classification, conformity assessment, risk-management documentation, monitoring, incident handling or other applicable obligations.
For clinical AI that is not legally classified as high-risk, a proportionate safety case can still be useful as an organizational patient-safety method. The reason to build one is not necessarily that the law requires it; it is that the healthcare organization needs a coherent basis for deciding whether an AI-supported clinical workflow is acceptably safe.
The same distinction applies when AI is also regulated as a medical device.
Medical-device regulatory compliance does not replace local deployment assurance
Some clinical AI systems may fall within Viet Nam's medical-device regulatory framework, while others may not. The current consolidated decree-level framework is contained in Consolidated Document No. 08/VBHN-BYT dated 6 March 2026.
Where AI is regulated as a medical device, applicable classification, registration or other market-access requirements, technical documentation, risk-management requirements and post-market obligations can provide important product-level assurance. They do not automatically answer every safety question created when that product is introduced into one healthcare organization's particular clinical environment.
An inappropriate integration, a changed workflow, inadequate training, patient-identification error or unsafe interaction with another information system can create hazards even when the underlying product complies with its applicable regulatory requirements.
The prostate-cancer deployment safety-case study was developed around this exact gap: deployment context and interaction with the clinical workflow could introduce hazards not fully captured by product-level regulatory assessment.
The practical principle is:
product assurance and deployment assurance are complementary, not interchangeable.
A safety case should make uncertainty visible, and stay alive after go-live
A weak governance process converts uncertainty into confidence. A stronger safety case records what is not yet known.
Local validation may contain too few patients from an important subgroup. The organization may have only a few months of monitoring data. A rare failure mode may never have been observed. A model's behavior in an unusual workflow may remain uncertain. The vendor may provide limited information about training data.
Those limitations are not reasons to hide uncertainty. They are reasons to manage it.
The organization might initially restrict use, increase human review, exclude particular populations, conduct enhanced monitoring, require additional vendor evidence or delay deployment. In a credible assurance argument, an evidence gap remains visible as an evidence gap rather than being quietly converted into a confident claim.
This becomes especially important after go-live because the system being assured can change. A vendor may update the model. Input data may drift. Patient populations may change. Clinicians may adapt the workflow. Alert fatigue or overreliance may emerge. An interface update may alter user behavior, while performance may deteriorate in one subgroup even though aggregate performance remains stable.
NHS England's current clinical-safety training treats the Clinical Risk Management Plan, hazard log, Clinical Safety Case Report and safety-incident log as living documents. It emphasizes version control, review triggers, configuration management and traceability between hazards, controls and test evidence.
A clinical AI safety case should therefore define review triggers in advance. Relevant triggers might include a material model or software update, a new clinical use, changed integration, significant performance drift, a safety incident, newly identified hazard, repeated near misses, cybersecurity compromise, vendor safety notice, persistent unexpected override behavior, change in legal classification or expansion to a new site or patient population.
After a material change, the right question is not merely, “Has the software been updated?”
It is:
“Which parts of our safety argument are no longer supported by the evidence we previously relied upon?”
A safety case can be simple without being superficial
The phrase “safety case” can sound like a large engineering exercise involving specialist notation and hundreds of pages. It does not need to be.
The depth should be proportionate to clinical consequence, complexity and uncertainty. A lower-consequence AI function may need a concise assurance record connecting a relatively small number of hazards and controls to supporting evidence. A system that materially influences diagnosis or treatment may justify a substantially deeper clinical, technical, human-factors and operational argument.
Formal approaches such as Goal Structuring Notation (GSN) can be useful in complex cases because they visually connect claims, subclaims, context, assumptions and evidence. The prostate-cancer deployment safety-case study used GSN as part of its assurance methodology. Research on AI assurance cases for intelligent medical devices has similarly explored structured assurance-case patterns designed to address risks specific to AI-enabled medical systems.
A hospital does not need to adopt GSN to benefit from the underlying logic. A well-designed table, linked digital record or structured assurance document can be sufficient if it clearly shows:
what we claim → what could make that claim false → what controls address those hazards → what evidence supports the controls → what risk remains → who accepted it → how we will continue checking it.
Clarity matters more than notation.
A practical Clinical AI Safety Case Framework
For a clinically consequential AI deployment, healthcare organizations can build a proportionate safety case around the following questions:
Top-level safety claim: What exactly are we claiming is acceptably safe, for which clinical purpose, population, site and workflow?
System boundary: Which AI product, model or deployment version, interfaces, data sources, users and downstream processes are included?
Intended use and exclusions: What is the AI allowed to do, what is outside its intended use, and in which patients or circumstances should it not be used?
Clinical workflow: Where does AI enter the care pathway, what information does it receive, who sees its output and what decisions or actions can follow?
Hazards: What reasonably foreseeable scenarios could harm patients, including model, data, integration, human-factors, cybersecurity, downtime and workflow failures?
Causes and pathways: How could each hazard arise, and how could that failure progress into patient harm?
Controls: Which technical, clinical, human and organizational measures reduce the likelihood or consequence of each hazard?
Control ownership: Who is responsible for implementing, checking and maintaining each material control?
Evidence: What testing, local validation, audit, simulation, monitoring, training or technical documentation demonstrates that important controls exist and work?
Evidence gaps: Where is evidence incomplete, indirect or uncertain, and what restrictions or enhanced monitoring compensate for that uncertainty?
Residual risk: What clinical risk remains after the controls are applied?
Risk acceptance: What criteria define acceptable residual risk, and who has authority to accept it for this deployment?
Regulatory alignment: What AI classification, conformity-assessment, medical-device, personal-data-protection, cybersecurity or other regulatory requirements apply?
Human oversight: If safety depends on human review, what evidence shows that review is meaningful and operationally feasible?
Fallback and failure: Can care remain safe during downtime, degraded performance or suspension?
Monitoring: Which safety, performance, subgroup, workflow and human-factors signals will be monitored after deployment?
Change triggers: Which changes to the model, software, data, workflow, population, integration or intended use require the safety case to be reviewed?
Incident learning: How will incidents, near misses and unexpected behavior update hazards, controls and evidence?
Exit: What circumstances would require restriction, suspension, withdrawal or decommissioning?
The Clinical AI Safety Case Framework is proposed here as a practical organizational assurance method. It is not a statutory checklist or legally prescribed document under Viet Nam's AI legislation.
A simple worked example: from hazard to residual risk
Consider an illustrative AI tool that helps prioritize imaging studies for clinician review. The organization identifies a clinically important hazard:
An urgent study is assigned a lower priority than appropriate.
Potential causes might include model error, incomplete data, an atypical presentation, local population differences, an integration fault or a software update. Harm could occur if inappropriate prioritization delays clinical review.
Controls might include local validation before routine deployment, preservation of an independent urgent pathway for defined cases, clear interface design, the clinician's ability to override the AI, downtime procedures and continuing performance monitoring.
Evidence supporting those controls could include local validation results, interface and integration tests, confirmation that designated urgent cases bypass the AI where required, simulation showing that staff can recognize and override inappropriate prioritization, competency evidence, monitoring of turnaround times and retrospective review of false-negative prioritization events.
After those controls are applied, risk still remains. The AI may still fail in an unusual case. The safety argument therefore does not claim that the hazard has been eliminated; it argues that the defined controls reduce the hazard to a residual level the accountable organization considers acceptable for the defined use, based on available evidence and subject to continuing monitoring and specified review or stop triggers.
That is where hazard management becomes assurance.
What this means for healthcare organizations in Viet Nam
Viet Nam now has a substantially clearer AI governance environment than it did only a year ago. The AI Law has been effective since 1 March 2026, Decree No. 142 since 1 May 2026 and Decision No. 33 establishing the current high-risk list since 15 August 2026.
The legal framework, however, cannot by itself determine whether one particular deployment in one healthcare organization is safe enough.
Law establishes obligations. Regulatory processes provide one layer of assurance. Vendor evidence characterizes the product. Local validation tests relevant aspects of performance. Monitoring detects change. Incident-management systems identify and respond to failure.
A clinical AI safety case brings those pieces back to one practical question:
Does the available evidence support our claim that this AI-supported clinical workflow is acceptably safe here, today, under the conditions we have defined?
This approach is consistent with a wider international shift toward organization-level AI assurance. On 1 June 2026, Joint Commission launched its voluntary Responsible Use of AI in Healthcare certification for U.S. healthcare organizations. The program focuses on governance, data management, risk and bias reduction, ongoing monitoring and validation, and transparency, education and training. Importantly, it assesses organizational approaches to responsible AI use rather than certifying individual AI products or tools.
Those international approaches are not Vietnamese legal requirements. They nevertheless reinforce the same organizational reality: safe clinical AI is not demonstrated by one model metric, one certificate or one successful pilot.
It is demonstrated by a coherent chain from clinical hazard to control, from control to evidence, and from evidence to an accountable decision about residual risk.
The most useful leadership question is therefore not:
“Do we have all the required AI documents?”
It is:
“Can we show, with evidence, why we believe the remaining risks of this AI deployment are acceptable, and can we tell when that argument stops being true?”
That is what a clinical AI safety case should accomplish.
Professional education notice
This article is intended for professional education and knowledge exchange. It does not constitute individualized legal, regulatory, clinical, engineering, cybersecurity or medical-device advice.
The terms clinical AI safety case, Clinical AI Safety Case Framework, safety claim, evidence gap and residual clinical risk are used here as practical assurance and organizational-governance concepts. Viet Nam's Law on Artificial Intelligence, Decree No. 142/2026/NĐ-CP and Decision No. 33/2026/QĐ-TTg do not currently prescribe a universal healthcare document called a “clinical AI safety case.”
Residual clinical risk as used in this article should not be confused with statutory AI risk classification under Vietnamese law. They answer different questions: statutory classification determines which AI-law obligations apply, while residual clinical risk concerns what risk remains in the particular clinical deployment after specified controls have been applied.
For AI systems legally classified as high-risk, an organizational safety case does not replace statutory classification, conformity assessment, risk management, monitoring, incident handling or other applicable obligations. Where an AI system is also regulated as a medical device, applicable medical-device requirements continue to apply.
NHS DCB0160, NIST AI RMF, Joint Commission materials and international safety-case research are included as governance and assurance references. DCB0160 is an English clinical-safety standard and is currently under review by NHS England; NIST and Joint Commission materials likewise do not create legal obligations in Viet Nam unless separately made applicable through Vietnamese law, regulation, contract, certification commitment or another binding basis.
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] Ministry of Health of Viet Nam. Consolidated Document No. 08/VBHN-BYT on Medical Device Management. Consolidated 6 March 2026.
[5] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1.
[6] NHS England. Module 3.3 — Developing and Maintaining Safety Documentation. Clinical Risk Management Training. Updated 15 July 2026.
[7] NHS England. DCB0160 — Clinical Risk Management: Its Application in the Deployment and Use of Health IT Systems. Current published release: 2018 Update; review of DCB0129/DCB0160 underway in 2026.
[8] Jia Y, Verrill C, White K, et al. A deployment safety case for AI-assisted prostate cancer diagnosis. Computers in Biology and Medicine. 2025;192(Pt B):110237.
[9] Khadka A, Epiphaniou G, Maple C. Assuring Intelligent Medical Devices: AI Assurance Cases. Studies in Health Technology and Informatics. 2025;328:91–95.
[10] Joint Commission. Responsible Use of AI in Healthcare Certification. Launched 1 June 2026; voluntary organization-level certification in the United States.