Building a Safety Culture for Clinical AI in Viet Nam: Psychological Safety, Speaking Up, Near-Miss Reporting and Learning from Failure
IMPLEMENTATION INSIGHTS
Building a Safety Culture for Clinical AI in Viet Nam: Psychological Safety, Speaking Up, Near-Miss Reporting and Learning from Failure
IMPLEMENTATION INSIGHT
Last reviewed: 6 October 2026
A healthcare organization can have an AI governance committee, an incident-reporting system, monitoring dashboards and detailed policies and still fail to recognize that an AI system is becoming unsafe. Many of the earliest warning signs do not begin on a dashboard. They begin with a nurse who notices that an alert repeatedly arrives too late, a physician who thinks an AI recommendation looks unusual, a pharmacist who keeps correcting the same generated error, a patient who receives confusing automated information, or an IT team that observes unexpected behavior after an update.
Whether those observations become organizational knowledge depends on culture. If people believe that questioning AI will make them look technologically resistant, admitting an override will be interpreted as poor performance, reporting an error will bring punishment, or nothing will happen after they speak up, weak safety signals can remain invisible until harm becomes more obvious. An organization may therefore have a reporting mechanism without having a genuine reporting and learning culture.
This distinction becomes increasingly important as clinical AI enters routine care. WHO treats incident-reporting and learning systems as part of the broader infrastructure for safer care and emphasizes the need to turn reports into learning and sustainable risk reduction [1,3]. In March 2026, Duke-Margolis Institute for Health Policy and Duke Health similarly argued that AI safety requires health systems to integrate AI oversight into existing patient-safety reporting structures, capture both adverse events and near misses, and move from reactive incident management toward proactive lifecycle risk management [2].
For healthcare organizations in Viet Nam, the practical question is therefore not simply “Do we have a way to report an AI incident?” It is “Will people recognize a weak signal, feel able to speak up, know where to report it, and trust that the organization will learn from what they report?”
Safety culture is more than an incident-reporting system
A reporting form is a tool. Safety culture is the environment in which people decide whether using that tool is worthwhile and safe. In a strong safety culture, staff understand that identifying hazards is part of professional responsibility. Leaders take weak signals seriously. People can question decisions and raise uncertainty. Reports are reviewed for system learning rather than immediately reduced to individual blame. Lessons are fed back into practice, and corrective actions are checked to determine whether they actually work.
WHO's technical guidance on patient-safety incident reporting emphasizes that incident data are valuable only when organizations understand their limitations, analyze them carefully and use the learning to reduce risk and improve safety [3].
Clinical AI makes this cultural dimension especially important because AI failures may initially be ambiguous. A clinician may not know whether an unusual output reflects the model, source data, interface design, workflow, an update or simply an unusual patient. If staff believe they should report only when they can prove that AI caused harm, many useful signals will never reach governance.
A safer principle is that people should be able to report uncertainty and concern before they can prove causation.
Psychological safety is necessary for speaking up
Psychological safety does not mean that everyone agrees. It means people believe they can raise a concern, admit uncertainty, ask for help or challenge an assumption without unreasonable fear of humiliation, retaliation or damage to their professional standing.
That matters greatly in healthcare because clinical work is often hierarchical. Junior staff may hesitate to challenge senior clinicians. Nurses may see workflow problems before physicians do but may not feel that technology decisions are “theirs” to question. Clinicians may assume that an AI system has already been thoroughly reviewed because leadership purchased it. Staff may also worry that reporting repeated AI overrides will be interpreted as poor adoption or resistance to innovation.
A 2026 review by Patole emphasizes the importance of psychological safety in healthcare, particularly in complex and hierarchical environments where team members may fear the consequences of speaking up [4].
Clinical AI also introduces an additional form of authority: technological authority. A system may carry the reputation of a major vendor, advanced mathematics or regulatory review. Its output may appear precise and objective, so staff may feel that disagreeing with AI requires greater confidence than disagreeing with an ordinary colleague.
A safety culture should explicitly counter that effect. Raising a credible concern about AI is not evidence of technological incompetence. It is part of responsible clinical oversight.
Psychological safety does not mean the absence of accountability
The language of “no blame” can help organizations encourage reporting, but it can also be misunderstood. A mature safety culture should not promise that nothing ever has consequences. Patient safety requires both learning and accountability.
The concept of a just culture is useful here. Just-culture approaches seek to understand system factors while distinguishing ordinary human error from at-risk or deliberately unsafe behavior rather than deciding responsibility solely from the severity of the outcome [5].
For clinical AI, this distinction matters. A physician who reasonably overrides an unreliable AI recommendation should not be treated like a clinician who knowingly ignores an essential safety requirement. A nurse who fails to respond because an alert is buried among hundreds of low-value notifications raises a different governance problem from a staff member who deliberately bypasses an established control without justification.
Likewise, if a clinician trusts an AI output because the organization trained users to rely on it and the interface strongly presents it as authoritative, blaming that individual alone after an error may prevent the organization from understanding a deeper system failure.
The objective should therefore be learning with fair accountability, not indiscriminate punishment and not indiscriminate immunity.
AI changes what people need to notice and report
Traditional patient-safety systems were not designed specifically for AI. An AI-related concern may therefore look different from a conventional medical incident. There may be no obvious equipment failure. The patient may never know AI was involved. A clinician may correct an output before harm occurs. Several small errors may occur across different patients without any one event appearing serious. A model may gradually become less reliable rather than suddenly fail.
Duke-Margolis identifies several reasons AI safety problems may escape conventional reporting, including difficulty recognizing recurring AI errors, rapidly changing software, incomplete awareness of which AI tools are embedded in workflows and limited patient visibility into AI's role in care [2].
Healthcare organizations should therefore make clear that reportable AI safety signals can extend beyond confirmed harm. Examples may include repeated implausible outputs, unexpected changes after an update, recurrent overrides for the same reason, systematic errors in generated documentation, subgroup performance concerns, unusual alert volumes, use outside intended conditions, missing or corrupted inputs, outputs arriving too late to be clinically useful, automation bias, unsafe workarounds, unexplained discrepancies between AI and clinical judgment, or patient-facing systems providing confusing or inappropriate information.
The purpose is not to classify every AI mistake as a medical incident. It is to create a route through which potentially meaningful signals can be assessed.
Near misses are particularly valuable in clinical AI
A near miss can reveal a pathway to harm before serious injury occurs. Circular No. 43/2018/TT-BYT defines a near miss as a situation that occurred without causing consequences, or nearly occurred but was detected and prevented in time before causing harm to the patient's health [6]. The Circular provides a framework for medical-incident identification, reporting, analysis, feedback and prevention.
The text of Circular No. 43 also distinguishes voluntary and mandatory reporting according to the nature and severity of medical incidents. However, the National Legal Database currently records the Circular as partially expired. Healthcare organizations should therefore confirm the current operative status of relevant provisions, together with later applicable law, before treating individual provisions as current legal obligations [6].
Near misses may be especially informative in clinical AI because human intervention often prevents harm. A radiologist may recognize that an AI-prioritized image has been ranked incorrectly and correct it. A physician may identify a generated medication instruction as wrong before signing the note. A nurse may reject an implausible deterioration score and escalate the patient based on clinical judgment. A pharmacist may catch a recurring documentation discrepancy.
If organizations record only the final outcome, no harm occurred, they lose evidence that a safety barrier was challenged. A more useful question is “What might have happened if nobody had noticed?”
Corrected AI errors should not disappear
Effective human oversight can paradoxically make a weak AI system appear safer than it actually is. If clinicians routinely identify and correct AI mistakes, patient outcomes may remain acceptable, and an adverse-event dashboard may look reassuring even though substantial human effort is compensating for weaknesses in the technology.
Repeated correction can therefore become an important safety signal. Healthcare organizations should consider patterns such as recurring overrides, edits to AI-generated documentation, cancelled AI-triggered actions, repeated clinician reclassification, unusual verification requests or workarounds developed to avoid particular outputs.
This does not mean that every override proves the AI was wrong. Clinicians may override correct recommendations for legitimate contextual reasons. The point is that recurring patterns should become investigable organizational data rather than disappear inside individual encounters.
Internal reporting thresholds should be lower than statutory serious-incident thresholds
Internal patient-safety reporting and statutory reporting of serious AI incidents serve different purposes and should not be confused.
Law No. 134/2025/QH15 on Artificial Intelligence defines the concept of a serious AI incident, while Article 19 of Decree No. 142/2026/NĐ-CP establishes the reporting and handling framework for incidents meeting that statutory threshold [7,8]. The consequences include death or serious harm to human health, significant property damage or serious effects on organizational operations, serious infringement of human rights or lawful rights and interests, and serious disruption of public or essential services or impacts on national security, social order or safety.
When a serious incident occurs, deployers and users must promptly record the incident, take necessary measures to limit consequences and notify the AI provider so remediation can be coordinated. The provider must take necessary technical measures to prevent, limit and remedy the consequences, while the provider and deployer have coordination responsibilities under the Decree [8].
For preliminary regulatory reporting, the AI provider or deployer must report through the AI one-stop electronic information portal. The deadline is 72 hours from confirmation of the incident for incidents involving death or serious harm to health, serious disruption of public or essential services or impacts on national security, social order or safety, and uncontrollable cases involving serious infringement of human rights or lawful rights and interests. Other serious incidents are subject to a five-working-day preliminary reporting deadline [8].
These are formal regulatory thresholds and timelines. They should not become the point at which a healthcare organization first starts paying attention.
A repeated near miss, unusual AI output, workflow concern or increase in overrides may never meet the statutory definition of a serious AI incident. It may nevertheless warrant internal patient-safety review, technical investigation, provider notification, enhanced monitoring or temporary restriction.
A mature organization therefore distinguishes between an internal safety-signal threshold, intentionally sensitive and designed for early learning, and a formal statutory reporting threshold, determined by applicable law. Confusing them would cause the organization to learn too late.
Make AI safety reporting easy enough to use
Safety culture deteriorates when reporting becomes difficult. If reporting an AI concern requires frontline staff to determine the correct legal category, identify the model version, find a specialized committee and complete a technical questionnaire, many useful observations will remain informal conversations.
Healthcare organizations should therefore consider adding an AI-related flag or pathway to existing patient-safety reporting systems rather than expecting every staff member to navigate a completely separate reporting infrastructure. Duke-Margolis similarly recommends integrating AI oversight into existing patient-safety reporting systems [2].
A frontline report should be able to begin with plain language: “Something about the AI did not look right.” The organization can classify the signal later. The reporter should not need to determine whether the problem represents drift, hallucination, automation bias, data-lineage failure, an integration problem or a vendor change. Those are questions for investigation.
The reporting burden should be proportionate to the reporter's role.
Capture enough information to learn from the event
A low-burden report still needs enough context to support learning. Useful information may include the system involved, clinical or operational setting, date and time, what the AI produced or did, what the user expected, what happened next, whether a patient was affected, whether a clinician corrected, rejected or overrode the output, whether the problem appeared reproducible and whether similar events had been seen before.
Where feasible and appropriate, technical investigation can later add the system version, relevant inputs, recent updates, logs, integration status and vendor or AI-provider information.
Frontline staff should not be expected to supply all of this technical material themselves. The initial report should capture the clinical or operational story, while governance and technical teams add system evidence during investigation. That division makes reporting both usable and analytically valuable.
Patients and caregivers can also identify AI safety signals
Healthcare workers are not the only people who can detect AI-related problems. Patients may notice that an AI-generated summary contains information that was never discussed. A chatbot may provide contradictory instructions. An ambient AI scribe may document something inaccurately. An automated pathway may make it repeatedly difficult to reach a clinician. Caregivers may recognize that AI-generated recommendations do not match what is happening at home.
Traditional complaints, record-correction requests and patient-experience systems can therefore contain AI safety signals even when nobody labels them that way.
Organizations should consider how relevant patient and caregiver feedback reaches AI governance. This does not mean every complaint involving technology becomes an AI incident. It means the organization needs enough visibility to recognize patterns when AI may have materially contributed to the experience or safety concern.
Frontline staff need more than permission to speak up
Leadership may tell staff, “You are encouraged to speak up.” Staff learn whether that statement is credible by watching what happens after someone actually does so.
If the first clinician who questions an AI tool is dismissed as resistant, the formal policy becomes less meaningful. If nurses repeatedly report an alert problem and never hear what happened, future reporting is likely to decline. If an incident investigation begins by asking who made the mistake rather than what happened and why, people will adapt accordingly.
Safety culture is therefore created through repeated organizational responses, not slogans.
Leaders should examine how managers respond to uncertainty, disagreement and bad news. Are staff thanked for raising a credible concern? Is the event investigated before blame is assigned? Are recurring AI issues escalated appropriately? Do people see evidence that reports lead to action?
WHO's reporting and learning guidance emphasizes the importance of feedback and closing the learning loop so that reporting contributes to risk reduction and improvement [3]. Staff do not necessarily need access to confidential details of every investigation, but they should have reasonable evidence that reporting leads somewhere.
The first question after an AI event should not be “Who made the mistake?”
When an AI-related event occurs, the easiest explanation may be user error. Sometimes individual behavior will indeed matter, but it should not automatically be the starting assumption.
A clinician may have misunderstood an output because training was inadequate. The interface may have communicated uncertainty poorly. The system may have created too many alerts. An update may have changed performance. The workflow may have created unrealistic response expectations. Input data may have been incomplete. The AI may have been applied outside the conditions or population for which it was evaluated.
A systems-oriented investigation asks: What happened? What conditions made it possible? What defenses worked? What defenses failed? Why did the action make sense to the person at the time?
Only after understanding those conditions should the organization consider whether the event primarily reflects system design, implementation, ordinary human error, at-risk behavior, deliberate disregard of safety requirements or a combination of factors.
A just-culture approach does not remove individual responsibility. It prevents individual blame from becoming a substitute for understanding how the healthcare system created or amplified risk.
AI can introduce new forms of attribution error
AI contribution may be difficult to recognize in conventional incident classifications. If a clinician follows an incorrect AI recommendation, an event may be recorded simply as a diagnostic or clinical decision error. If generated documentation introduces an incorrect medication, the event may appear only as a documentation problem. If AI prioritization delays review, the problem may be classified as workflow delay.
Those classifications may be correct but incomplete. The governance question is whether the organization can also recognize AI as a contributing factor when appropriate.
Incident-reporting systems may therefore benefit from an AI-related field or structured review question such as “Did an AI-enabled system contribute to the event, decision, information, workflow or response?” Possible answers can include yes, no, possible or unknown, because attribution will frequently remain uncertain when a concern is first reported.
Requiring certainty too early can suppress useful signals.
Review patterns, not only individual reports
One isolated concern may represent noise. Ten similar concerns may reveal a pattern.
AI governance therefore needs mechanisms to aggregate safety signals across time, departments and sites. Repeated overrides, similar documentation corrections, clustered complaints, rising alert volume or recurrent errors after a particular update may become visible only when observations are reviewed collectively.
Duke-Margolis emphasizes systematic tracking because individual AI safety events and near misses can vary in severity while patterns may reveal broader weaknesses [2].
Incident review should therefore operate at two levels: case review, asking what happened in this patient encounter or workflow, and pattern review, asking what the organization is learning about the AI system over time.
AI safety review should be multidisciplinary
An AI safety concern rarely belongs to only one organizational function. Clinical teams may understand the patient context. Quality and patient-safety staff understand incident analysis. IT may identify integration failures. Data teams may recognize input changes. Cybersecurity teams may identify a security issue. A vendor or statutory AI provider may have information about updates, known defects, logs or similar events.
Depending on the concern, review may therefore require clinical, quality, patient-safety, data, technical, privacy, cybersecurity, legal or vendor expertise.
Joint Commission's voluntary U.S. Responsible Use of AI in Healthcare certification similarly treats health-AI safety as an organizational governance issue and includes processes for lifecycle monitoring as well as internal and external reporting of health-AI safety-related events [9]. These are not legal requirements for healthcare organizations in Viet Nam, but the organizational principle is useful.
The purpose is not to send every concern to a large committee. It is to ensure that a meaningful signal can reach the expertise needed to understand it.
Vendor or AI-provider involvement should not replace organizational investigation
When an AI problem emerges, the healthcare organization may need assistance from a commercial vendor or statutory AI provider. They may hold information about model behavior, technical logs, known defects, updates or similar problems reported elsewhere.
That support is important, but the healthcare organization should not simply forward a concern and consider its own governance responsibility complete.
The organization understands the local workflow, staffing, patient population, downstream capacity and human response. A vendor may correctly determine that the software operated according to specification while the healthcare organization correctly concludes that the same system remains unsafe or unsuitable in the local care pathway.
AI safety should therefore be investigated as a sociotechnical event, not solely as a software defect.
Learning requires corrective action and remeasurement
A safety culture does not end with identifying a cause or issuing a recommendation. Suppose an investigation finds that clinicians regularly miss a deterioration alert because it appears among many lower-priority notifications. The organization changes the interface and escalation process. The next question is whether missed alerts actually decrease.
If they do not, an action has been documented but improvement has not been demonstrated.
The learning cycle should therefore be:
signal → report → triage → investigate → act → remeasure → learn
For important AI-related concerns, organizations should determine whether corrective actions were implemented, whether they addressed the relevant causes, whether unintended consequences appeared and whether the original safety signal changed afterward.
That is how incident reporting becomes improvement rather than administration.
Close the loop with the person who spoke up
Reporting systems lose credibility when information goes in but nothing comes back. Not every reporter can receive detailed or confidential investigation findings, but healthcare organizations should establish reasonable feedback mechanisms. Staff may be told that a concern was reviewed, whether it was escalated, whether monitoring increased or what general category of corrective action followed.
When a report leads to useful improvement, appropriately sharing that learning with the wider workforce can strengthen both safety knowledge and confidence in the reporting process.
A safety culture grows when people can reasonably say: “I raised a concern, and the organization did something useful with it.”
Do not measure safety culture by report volume alone
An increase in incident reports does not necessarily mean care has become less safe. It may indicate that people feel safer reporting. Conversely, a very low number of reports does not prove excellent safety; it may reflect under-recognition, fear, reporting burden or distrust.
Healthcare organizations should therefore avoid using the number of AI safety reports as a simple performance target.
More meaningful measures may include near-miss reporting; time from report to initial review; proportion of reports receiving feedback; recurrence of similar concerns; completion and effectiveness of corrective actions; staff perceptions of speaking up; awareness of reporting pathways; and whether relevant signals from one site are shared with others when appropriate.
The aim is not to maximize reporting volume. It is to increase visibility, learning and risk reduction.
Multi-site organizations need shared learning without losing local context
A healthcare group may use the same AI system across several hospitals or clinics. A near miss at one site can therefore provide an early warning to others.
If one facility discovers that an AI system behaves differently after a particular integration change, other sites may need to know. If nurses at one location identify an unsafe workaround, the organization should ask whether similar workflow pressure exists elsewhere.
At the same time, local context matters. Sites may differ in patient populations, staffing, equipment, information systems and escalation pathways.
The strongest multi-site safety model therefore combines rapid shared learning with local investigation. An event should neither remain trapped within one facility nor automatically be generalized to every site without considering context.
Learning from failure includes knowing when to stop
Safety culture is sometimes framed as improving a system until it works. Responsible AI governance requires another possibility: sometimes the appropriate lesson is that the technology should not continue in its current form.
Repeated near misses, unresolved inequity, excessive override burden, unreliable data inputs, persistent workflow failure or inability to maintain meaningful human oversight may justify restriction or suspension. If evidence continues to show that expected benefits are not materializing, decommissioning may eventually be appropriate.
This is not necessarily a failure of innovation. It can be evidence that governance is functioning.
A culture that can report problems but cannot act against a favored technology is not yet a strong safety culture.
Psychological safety also matters when leaders are enthusiastic about AI
Reporting may become particularly difficult when an AI initiative has strong executive sponsorship. Staff may worry that criticizing a flagship innovation will reflect poorly on them. Teams may have invested substantial money, time and reputation in implementation. Project leaders may unintentionally interpret credible safety concerns as resistance to change.
This is one reason safety governance needs enough independence from innovation advocacy to evaluate concerns fairly.
Leaders should communicate explicitly that raising credible concerns is compatible with supporting innovation. Responsible innovation depends on discovering problems early. A useful leadership principle is: “We want this technology to succeed only if it makes care safer or better.”
That gives the organization permission to discover that an earlier assumption was wrong.
Patients and families should see evidence that the organization learns
Patient-safety culture is ultimately about the people receiving care. Patients and families who identify AI-related concerns should have accessible ways to raise them, particularly where AI communicates directly with them or materially affects the care pathway.
Where an event causes harm, applicable requirements concerning disclosure, communication and patient rights remain governed by the relevant legal and clinical frameworks. AI does not create a general exception simply because technology contributed to the event.
More broadly, organizations should be able to demonstrate that complaints, corrections and safety concerns contribute to learning. Trust in healthcare AI will not come only from explaining how advanced the technology is. It will also depend on demonstrating what the organization does when the technology may be wrong.
A practical Clinical AI Safety Culture Loop
Healthcare organizations in Viet Nam do not need to create an entirely new safety culture exclusively for AI. Existing patient-safety principles can be extended through a practical loop:
notice → speak up → capture → triage → investigate → act → give feedback → remeasure → learn → spread
Notice means helping staff and patients recognize that AI may contribute to safety problems even when no obvious technical failure occurs. Speak up means creating psychological safety so that uncertainty, disagreement and near misses can be raised early. Capture means providing an accessible reporting route that records sufficient clinical or operational context without expecting frontline users to diagnose the technical cause.
Triage means distinguishing urgent clinical concerns, recurring patterns, possible serious incidents and lower-level signals requiring observation. Investigate means considering human, technical, data, workflow, organizational and vendor factors rather than defaulting to individual blame. Act means implementing proportionate controls, which may involve workflow redesign, training, interface changes, additional monitoring, provider action, restriction or suspension.
Give feedback means closing the loop with reporters and relevant teams. Remeasure means checking whether corrective actions actually changed the safety signal. Learn means retaining the lesson as institutional knowledge, while spread means communicating relevant lessons to other departments or sites before the same failure is repeated.
This Clinical AI Safety Culture Loop is proposed here as a practical organizational framework. It is not a statutory framework under Vietnamese law, an official Ministry of Health patient-safety model or a certification requirement.
Existing Vietnamese quality and safety systems should remain the foundation
Healthcare organizations in Viet Nam already have structures into which AI safety can be integrated.
Circular No. 19/2013/TT-BYT remains recorded as in force and provides an established hospital quality-management framework, including organizational responsibilities, quality indicators and continuous improvement [10].
Circular No. 43/2018/TT-BYT provides a framework for medical-incident identification, reporting, analysis, feedback and prevention and expressly recognizes near misses. Its text also emphasizes incident analysis and learning for prevention, together with confidentiality and organizational support for incident-prevention activities. Because the National Legal Database currently records Circular No. 43 as partially expired, healthcare organizations should confirm the operative status of individual provisions together with later applicable law before treating them as current legal requirements [6].
The practical objective should therefore not be to create an “AI patient-safety system” separate from the hospital's existing quality system. It should be to ensure that AI becomes visible inside the quality and patient-safety system the organization already has.
What this means for healthcare organizations in Viet Nam
Clinical AI safety depends on more than model accuracy, regulatory classification and technical monitoring. It depends on whether people can recognize when something seems wrong, whether clinicians can disagree with AI, whether nurses, pharmacists, technicians and other staff believe their observations matter, whether patients and caregivers have a route to raise concerns, and whether leaders respond to bad news with disciplined curiosity rather than defensiveness.
The hardest safety signals to capture may not be dramatic failures. They may be small corrections, recurring workarounds, repeated overrides, near misses and comments such as “this system has been behaving differently recently.” These signals are easy to dismiss, but they may represent the organization's best opportunity to learn before serious harm occurs.
The transition healthcare organizations need is therefore:
from waiting for AI harm → to noticing weak signals → to making speaking up safe → to learning from near misses → to changing the system before failure repeats
A healthcare organization with sophisticated AI technology but a weak speaking-up culture remains vulnerable. Responsible healthcare AI requires both good technology and an organization willing and able to hear when that technology may be wrong.
Professional education notice
This article is intended for professional education and knowledge exchange. It does not constitute individualized legal, regulatory, clinical, human-resources, disciplinary, employment-law, accreditation or quality-management advice.
The concepts of psychological safety, safety culture and just culture are used here as healthcare quality, patient-safety and organizational-learning concepts. They should not be interpreted as creating immunity from professional, disciplinary, employment, civil, administrative or criminal responsibility where such responsibility applies.
Encouraging non-punitive reporting does not mean eliminating accountability. Healthcare organizations should distinguish ordinary human error and system-induced behavior from at-risk, deliberately unsafe or reckless conduct using fair, consistent processes and applicable law and professional standards.
Internal AI safety reporting should not be confused with statutory reporting of serious AI incidents under Law No. 134/2025/QH15 and Decree No. 142/2026/NĐ-CP, or with applicable medical-incident reporting obligations. Different thresholds, responsible parties and reporting pathways may apply.
The Clinical AI Safety Culture Loop proposed in this article is a practical organizational framework. It is not an official Vietnamese regulatory framework, WHO standard, Joint Commission requirement or validated safety-culture instrument.
References
World Health Organization. Patient Safety Guidance and Tools: Incident Reporting and Learning Systems. Current WHO patient-safety resource.
Joyce C, Economou-Zavlanos NJ, Silcox C. AI Safety in Health Systems: Building Infrastructure and Strengthening Risk Management Practices. Duke-Margolis Institute for Health Policy and Duke Health. Published 26 March 2026.
World Health Organization. Patient Safety Incident Reporting and Learning Systems: Technical Report and Guidance. Published 16 September 2020.
Patole S. Psychological safety in healthcare – helping everyone to speak up. Seminars in Fetal and Neonatal Medicine. 2026;31(3):101738.
Agency for Healthcare Research and Quality. Culture of Safety and related patient-safety culture and just-culture resources.
Ministry of Health of Viet Nam. Circular No. 43/2018/TT-BYT Providing Guidance on Prevention of Medical Incidents in Medical Examination and Treatment Establishments. Issued 26 December 2018; effective 1 March 2019; currently recorded in the national legal database as partially expired.
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. Issued 30 April 2026; effective 1 May 2026.
Joint Commission. Responsible Use of AI in Healthcare Certification. Launched 1 June 2026.
Ministry of Health of Viet Nam. Circular No. 19/2013/TT-BYT Providing Guidance on Management of Quality of Medical Examination and Treatment Services in Hospitals. Issued 12 July 2013; effective 15 September 2013; currently recorded as in force.