InfiniSynapse
What are root cause analysis techniques?什么是根因分析技术？
For the full topic map and the neighboring methods that support this workflow, continue with the anomaly detection and root cause analysis guide.
如需查看完整主题结构以及支撑本流程的相邻方法，请继续阅读异常检测与根因分析指南。
Root cause analysis techniques are structured ways to define a problem, generate possible explanations, test those explanations against evidence, and choose corrective actions that address the conditions behind recurrence. The best-known techniques include 5 Whys, fishbone diagrams, Pareto analysis, fault tree analysis, change analysis, barrier analysis, timelines, and causal-factor mapping. A technique structures thinking; it does not make an untested explanation true.
根因分析技术是一组结构化方法，用于界定问题、生成可能解释、用证据检验这些解释，并选择能够处理复发条件的纠正措施。常见方法包括五问法、鱼骨图、帕累托分析、故障树分析、变更分析、屏障分析、时间线和因果因素图。方法可以组织思考，但不会让未经检验的解释自动成为事实。
People searching for root cause analysis techniques usually need more than a list: they need to know which method fits a narrow failure, a multi-factor process, an interacting technical system, or a change-driven incident. This guide therefore treats selection, combination, evidence testing, and follow-up as one workflow. It covers retrospective investigation; prospective risk tools such as FMEA are compared where they clarify the boundary.
搜索根因分析技术的用户通常不只需要一份名称清单，还需要判断哪种方法适合单一路径故障、多因素流程、存在交互关系的技术系统或由变更触发的事件。因此，本指南把方法选择、组合、证据检验和后续验证视为同一工作流。正文重点是回顾性调查，同时在有助于厘清边界时比较 FMEA 等前瞻性风险工具。
Prepare evidence before applying root cause analysis techniques应用根因分析技术前先准备证据
Begin with a neutral problem statement that identifies the observed deviation, affected process, location, time window, impact, and exclusions. Write “batch 417 exceeded the validated temperature range for 11 minutes,” not “the operator overheated batch 417.” The second version has already selected a cause and will bias every later question.
先编写中性问题陈述，说明已观察到的偏差、受影响流程、地点、时间窗口、影响和排除项。应写“批次 417 超出已验证温度范围 11 分钟”，而不是“操作员使批次 417 过热”。后者已经预选了原因，会让后续问题产生偏差。
Expected baseline, event timeline, raw measurements, logs, configuration versions, alarms, work records, physical evidence, interviews, and comparable normal runs.
预期基线、事件时间线、原始测量、日志、配置版本、告警、作业记录、物理证据、访谈以及可比较的正常运行。
Investigation owner, subject experts, scope, evidence custodian, risk level, approval route, access restrictions, due date, and the standard required to close or reopen the case.
调查负责人、主题专家、范围、证据保管人、风险等级、审批路径、访问限制、截止日期以及结案或重新开启所需标准。
Preserve volatile evidence before restarting, reconfiguring, cleaning, or repairing when safety and procedure allow. Normalize time zones and units, but retain originals. Mark missing, conflicting, and inferred fields rather than silently completing them. For healthcare, safety, financial, legal, or regulated events, follow the applicable approved process and use qualified reviewers; this general guide is not a substitute for professional or regulatory obligations.
在安全且程序允许时，应在重启、重新配置、清洁或维修之前保存易消失证据。可以统一时区和单位，但要保留原始值。对缺失、冲突和推断字段进行标记，不要静默补全。涉及医疗、安全、金融、法律或监管事件时，应遵循适用的批准流程并使用合格复核人员；本通用指南不能替代专业或监管义务。
Compare root cause analysis techniques by problem shape按问题形态比较根因分析技术
| Technique技术 | Best use适用情况 | Output输出 | Main limit主要局限 |
|---|---|---|---|
| 5 Whys | Narrow, mostly linear problem with process knowledge较窄、近似线性且参与者熟悉流程的问题 | Traceable causal chain可追踪因果链 | Can stop early or follow one favored story可能过早停止或只追随偏好的解释 |
| Fishbone diagram鱼骨图 | Multi-cause problem needing cross-functional exploration需要跨团队探索的多原因问题 | Categorized hypothesis map分类候选原因图 | Brainstormed branches are not evidence头脑风暴分支不是证据 |
| Pareto analysis帕累托分析 | Prioritizing frequent or costly categories按频次或成本确定类别优先级 | Ranked contribution chart贡献度排序图 | Prioritizes where to look, not why it happened说明先查哪里，不直接说明为何发生 |
| Fault tree analysis故障树分析 | Logic-driven, safety-critical, multi-path failure逻辑驱动、安全关键、多路径故障 | AND/OR failure logicAND/OR 故障逻辑 | Requires system expertise and disciplined assumptions需要系统专家与严格假设 |
| Timeline and change analysis时间线与变更分析 | Incidents with deployments, configuration, staffing, or environment shifts涉及发布、配置、人员或环境变化的事件 | Before/after evidence and temporal sequence变更前后证据与时序 | Temporal order alone does not prove causation时间先后本身不能证明因果 |
| Barrier analysis屏障分析 | Controls that failed, were absent, or were bypassed控制措施失效、缺失或被绕过 | Prevention and detection control gaps预防与检测控制缺口 | Needs an accurate control model依赖准确的控制模型 |
The techniques are complementary, but each must perform a distinct job. Pareto analysis can choose which defect family deserves attention; a fishbone diagram can expand the hypothesis space; 5 Whys can deepen an evidence-supported branch; fault-tree or barrier analysis can model interactions and safeguards. Do not use more diagrams than the decision requires. Technique selection should follow the shape of the uncertainty and the strength of available evidence.
这些技术可以组合，但每一种都应承担不同任务。帕累托分析可选择值得优先调查的缺陷类别；鱼骨图可扩大候选假设范围；五问法可深入有证据支持的分支；故障树或屏障分析可建模交互关系与安全控制。不要为了形式使用超出决策需要的图表。技术选择应服从不确定性的形态和现有证据强度。
RCA versus FMEA: root cause analysis is usually retrospective—it asks why an observed event occurred. Failure mode and effects analysis is usually prospective—it asks what could fail, how severe the effect would be, and what controls exist before the event. RCA findings can update an FMEA, but FMEA risk rankings do not prove the cause of a specific incident.
RCA 与 FMEA：根因分析通常是回顾性的，回答已经观察到的事件为何发生；失效模式与影响分析通常是前瞻性的，在事件发生前评估什么可能失效、影响有多严重以及存在哪些控制。RCA 结论可用于更新 FMEA，但 FMEA 风险排序不能证明某个具体事件的原因。
Keep a shared evidence matrix when techniques are combined. Use one row per causal claim and record the technique that produced it, source records, expected observation, contradictory evidence, test owner, status, and confidence. This prevents the same unsupported idea from appearing in several diagrams and looking stronger merely through repetition. It also makes handoffs auditable: a reviewer can see whether a branch came from brainstorming, a measured comparison, a reproduced mechanism, or a control test. Promote a candidate to an accepted cause only when it explains the event boundary, survives a meaningful alternative, and identifies a changeable condition. Otherwise label it contributing, unresolved, or rejected.
组合技术时应维护共享证据矩阵。每条因果主张占一行，记录产生它的技术、来源记录、预期观察、矛盾证据、检验负责人、状态和置信度。这样可避免同一项无证据想法因重复出现在多张图中而显得更可信，也让交接可审计。只有当候选原因能解释事件边界、经受有意义的替代解释检验并指向可改变条件时，才提升为已接受原因；否则应标记为促成因素、未解决或已排除。
A practical playbook for six RCA techniques六种 RCA 技术的实用使用手册
A technique is useful only when its input, output, and stopping rule are explicit. The following playbook prevents a workshop artifact from being mistaken for a verified causal conclusion.
只有在输入、输出和停止规则明确时，技术才真正有用。以下手册可避免把研讨产物误当成已经验证的因果结论。
Input: one well-bounded failure path. Output: a provisional chain from event to controllable condition. Ask for evidence at every “because,” branch when answers diverge, and stop when the next answer is outside the case boundary or cannot be tested. Do not force exactly five questions.
输入：一条边界清楚的失效路径。输出：从事件到可控制条件的暂定链。每个“因为”都要有证据；答案分叉时建立分支；下一个答案超出范围或无法检验时停止，不必强求正好五问。
Input: a clear effect and a diverse team. Output: a categorized hypothesis inventory. Require a mechanism, likely evidence, and owner for every serious branch. Merge duplicates, mark assumptions, and stop brainstorming when new branches repeat old mechanisms. The next step is testing, not voting.
输入：清晰结果与多元团队。输出：分类的假设清单。每个重要分支都应写明机制、预期证据和负责人；合并重复项并标记假设。新分支只重复旧机制时停止头脑风暴，下一步应检验而非投票。
Input: consistently classified events with a meaningful denominator. Output: ranked categories for investigation. Check whether categories overlap, whether severity matters more than frequency, and whether collection bias changes the ranking. Stop after selecting priorities; a tall bar is not a root cause.
输入：分类一致且具有合理分母的事件。输出：调查优先级排序。检查类别是否重叠、严重度是否比频次更重要，以及采集偏差是否改变排序。确定优先级后即停止；高柱并不等于根因。
Input: affected and unaffected periods, units, or configurations. Output: discriminating differences and testable mechanisms. Align clocks, include gradual and undocumented changes, and check co-occurring factors. Stop only after the suspected difference predicts the event boundary better than competing changes.
输入：受影响与未受影响的时段、单元或配置。输出：有区分力的差异与可检验机制。对齐时钟，纳入渐进和未记录变更，并检查同期因素；只有当疑似差异比竞争变更更好解释事件边界时才停止。
Input: the hazard path and intended prevention, detection, mitigation, and recovery controls. Output: absent, failed, bypassed, or degraded barriers. Test whether each control existed, was usable, and could act in time. Stop when every material path has an owner and a verified control gap or documented uncertainty.
输入：危险路径以及预防、检测、缓解和恢复控制。输出：缺失、失效、绕过或退化的屏障。检验控制是否存在、可用且能及时起效；每条重要路径都有负责人及已验证控制缺口或明确不确定性后停止。
Input: a precise top event, system boundary, and credible failure modes. Output: explicit AND/OR logic and minimal combinations capable of producing the event. Review dependencies and common causes before using probabilities. Stop when the tree supports the decision and all material assumptions are visible—not when every component has been expanded.
输入：精确定义的顶事件、系统边界和可信失效模式。输出：明确的 AND/OR 逻辑及可导致事件的最小组合。使用概率前复核依赖与共因；当树已支持决策且重要假设可见时停止，而非无限展开每个组件。
How to apply root cause analysis techniques step by step如何逐步应用根因分析技术
- Stabilize and define.稳定现场并定义问题。Protect people, service, product, and evidence first. Then state the observed gap, baseline, scope, time window, impact, exclusions, and immediate containment without naming a cause.首先保护人员、服务、产品和证据；随后陈述已观察到的偏差、基线、范围、时间窗口、影响、排除项和临时遏制措施，但不要提前命名原因。
- Reconstruct what happened.重建事件经过。Build a timestamped sequence from independent sources. Mark facts, observations, interview statements, calculations, assumptions, and gaps as different evidence types.使用独立来源建立带时间戳的事件序列，把事实、观察、访谈陈述、计算、假设和缺口标记为不同证据类型。
- Select the technique by uncertainty.按不确定性选择技术。Use a narrow chain when the mechanism is simple; a broad cause map when categories are unknown; a logic tree when paths interact; or change analysis when a transition provides a strong lead.机制简单时使用窄因果链；原因类别未知时使用宽范围原因图；路径交互时使用逻辑树；已知变更提供强线索时使用变更分析。
- Generate competing explanations.生成相互竞争的解释。For every candidate, state the proposed mechanism, predicted evidence, evidence against it, and the test that could distinguish it. Keep “unknown” available instead of forcing agreement.对每个候选原因写明拟议机制、预期证据、反对证据以及可区分它的检验。保留“未知”状态，不要强迫团队达成虚假一致。
- Test causes, controls, and alternatives.检验原因、控制和替代解释。Inspect counterexamples, compare normal cases, reproduce conditions only when safe, and examine why prevention or detection barriers failed. Record rejected hypotheses and reasons.检查反例、比较正常案例，只在安全时复现条件，并分析预防或检测屏障为何失效。记录被排除的假设及其理由。
- Act and verify over time.采取措施并持续验证。Link each corrective action to a supported cause or control gap. Define owner, due date, baseline, target, side-effect measure, verification window, and reopening rule before implementation.把每项纠正措施链接到有证据支持的原因或控制缺口，并在实施前定义负责人、截止日期、基线、目标、副作用指标、验证窗口和重新开启规则。
Example: combining RCA techniques for a recurring pipeline delay示例：组合 RCA 技术调查反复出现的数据管道延迟
Hypothetical example: a daily data pipeline usually completes by 06:00, but it finished late on four consecutive Mondays. The team defines the deviation, affected reports, and time window without assuming that the database is slow. A timeline aligns source exports, file arrival, job starts, resource metrics, deployments, and alerts. Pareto analysis shows that one ingestion stage accounts for most excess duration.
假设示例：某每日数据管道通常在 06:00 前完成，但连续四个星期一延迟。团队先定义偏差、受影响报表和时间窗口，不假设“数据库很慢”。时间线对齐源系统导出、文件到达、作业开始、资源指标、发布和告警；帕累托分析显示，大部分额外耗时集中在一个摄取阶段。
A fishbone diagram expands the candidates across data, schema, infrastructure, scheduling, software, and process. Change analysis finds that one upstream export switched from incremental to full on weekends. The team then uses a short 5 Whys chain to ask why the mode changed and why no control caught the input-size jump. It does not stop at “the file was large,” because file size is the immediate mechanism, not the configuration and control story.
鱼骨图从数据、模式、基础设施、调度、软件和流程等类别扩展候选原因。变更分析发现，一个上游导出在周末从增量模式切换为全量模式。团队再用较短的五问链追问模式为何变化，以及为何没有控制发现输入大小突增。调查不会停在“文件很大”，因为文件大小只是直接机制，不是配置和控制层面的完整解释。
Tests compare normal and late runs: network throughput is similar, compute capacity has headroom, replaying the full export reproduces the delay, and replaying an incremental export does not. The resulting causal account includes the upstream configuration change, an absent maximum-size preflight check, and an alert that detects lateness only after the service target is missed. Each part has a different role: trigger, failed prevention control, and detection gap.
团队比较正常与延迟运行：网络吞吐相近、计算容量仍有余量；回放全量导出会复现延迟，而回放增量导出不会。最终因果说明包括上游配置变更、缺失的最大文件大小预检，以及只能在错过服务目标后发现问题的告警。三者角色不同，分别是触发因素、预防控制失效和检测缺口。
Corrective actions restore the intended export mode, add a preflight size rule, and alert on abnormal growth before ingestion. Verification examines several subsequent Monday runs and checks data completeness so faster execution does not hide dropped records. All numbers, systems, and results in this example are illustrative; they are not a customer case or an InfiniSynapse performance claim.
纠正措施包括恢复预期导出模式、增加文件大小预检规则，并在摄取前对异常增长告警。验证覆盖之后多个星期一运行，同时检查数据完整性，避免通过丢弃记录换取更快执行。此示例中的数字、系统和结果均为说明性假设，不是客户案例或 InfiniSynapse 性能声明。
Combine RCA techniques without confusing their outputs组合 RCA 技术时不要混淆不同输出
| Situation情形 | Sequence组合顺序 | Why it works组合理由 |
|---|---|---|
| Many recurring defect categories多个重复缺陷类别 | Pareto → fishbone → evidence tests帕累托 → 鱼骨图 → 证据检验 | Prioritize a family, broaden explanations, then confirm.先确定类别优先级，再扩展解释，最后确认。 |
| Single process failure with a known sequence顺序已知的单一流程故障 | Timeline → 5 Whys → barrier analysis时间线 → 五问法 → 屏障分析 | Trace the mechanism, then ask why controls did not prevent or detect it.先追踪机制，再询问控制为何没有预防或检测。 |
| Complex safety or reliability event复杂安全或可靠性事件 | Event reconstruction → fault tree → barrier tests事件重建 → 故障树 → 屏障检验 | Represent interacting paths and verify critical assumptions.表示交互路径并验证关键假设。 |
| Failure after a release or process transition发布或流程变更后的故障 | Change analysis → comparison cohort → focused causal map变更分析 → 对照组 → 聚焦因果图 | Use the change as a lead while testing whether it actually explains the event.把变更当作线索，同时检验它是否真正解释事件。 |
The output of one technique becomes an input to the next, not a conclusion by default. A Pareto bar is a priority signal; a fishbone branch is a hypothesis; a fault-tree path is a modeled possibility; a Five Whys chain is a proposed explanation. Confirmation requires source evidence, a plausible mechanism, comparison or reproduction where safe, and a defined test against alternatives.
一种技术的输出默认只是下一种技术的输入，而不是结论。帕累托条形是优先级信号；鱼骨图分支是假设；故障树路径是建模可能性；五问链是拟议解释。确认需要来源证据、合理机制、安全条件下的比较或复现，以及针对替代解释的明确检验。
Apply RCA techniques to connected evidence把 RCA 技术应用于关联证据
Before opening the workspace, prepare a scoped case folder, stable record IDs, a neutral problem statement, timeline, measurements, logs, documents, source references, and questions to test. InfiniSynapse supports AI-assisted analysis across connected databases, files, documents, audio, and video; this page does not present it as dedicated or certified RCA software. Use it to explore relationships and supporting evidence, then document and verify consequential conclusions through your approved investigation process.
打开工作区前，请准备范围明确的案件文件夹、稳定记录 ID、中性问题陈述、时间线、测量、日志、文档、来源引用和待检验问题。InfiniSynapse 支持跨关联数据库、文件、文档、音频和视频的 AI 辅助分析；本页不把它描述为专用或经过认证的 RCA 软件。可用它探索关系和支持证据，再通过组织批准的调查流程记录并验证重要结论。
Analyze connected RCA evidence in InfiniSynapse在 InfiniSynapse 中分析关联 RCA 证据Common RCA mistakes, limits, and risk controls常见 RCA 误区、局限与风险控制
- Stopping at human error: ask what conditions, controls, interfaces, training, workload, or incentives made the error possible and detectable.停在“人为错误”：继续检查哪些条件、控制、界面、培训、工作负荷或激励使错误成为可能，以及为何没有及时检测。
- Confusing correlation with cause: a variable that changes near an incident may be a consequence, proxy, or shared effect.把相关当因果：事件附近发生变化的变量可能是结果、代理变量或共同影响。
- Choosing one cause too early: keep competing explanations until evidence differentiates them.过早选择单一原因：在证据能够区分之前，应保留相互竞争的解释。
- Correcting the symptom: restarting a service, reworking a part, or retraining one person may restore operation without preventing recurrence.只纠正症状：重启服务、返工零件或重新培训某个人可能恢复运行，却不一定防止复发。
- Closing without verification: an assigned action is not an effective action until outcome and side-effect measures support it.未经验证就结案：措施被分配并不代表措施有效，必须由结果指标和副作用检查支持。
Important limitation: RCA looks backward from an event and is vulnerable to hindsight bias, incomplete records, organizational pressure, and overly simple causal stories. Record uncertainty and minority views, protect participants from blame-driven questioning, and reopen cases when new evidence or recurrence contradicts the conclusion.
重要局限：RCA 从事件结果向后追溯，容易受到后见之明偏差、记录不完整、组织压力和过度简化因果故事的影响。应记录不确定性与少数意见，避免以归责为导向的提问；当新证据或复发与原结论冲突时，应重新开启案件。
How to verify the cause and corrective action如何验证根因与纠正措施
Before accepting a root cause, ask four questions. Does it explain the timing, scope, and mechanism? Does it predict evidence that was not used to invent it? Have reasonable alternatives been tested? If the cause is controlled, should the event stop or materially change? Stronger investigations specify disconfirming evidence—the observation that would make the team abandon its favored explanation.
接受某个根因前，应提出四个问题：它是否解释时间、范围和机制？它能否预测提出假设时尚未使用的证据？合理的替代解释是否已经检验？控制该原因后，事件是否应停止或显著变化？更可靠的调查还会预先写明反证条件，即出现何种观察结果时团队必须放弃偏好的解释。
For the corrective action, record a baseline, target, measurement definition, owner, implementation date, verification window, review frequency, and possible side effects. Distinguish completion from effectiveness. If the target improves only because reporting, sampling, or demand changed, the result is not comparable. Monitor leading controls as well as lagging recurrence, and preserve enough history to audit the decision.
对纠正措施，应记录基线、目标、测量定义、负责人、实施日期、验证窗口、复核频率和可能副作用。必须区分“已完成”与“有效”。如果指标改善只是因为报告方式、抽样或需求发生变化，结果就不可比较。除滞后的复发指标外，还应监控前置控制，并保留足够历史以审计决策。
Best practices for defensible root cause identification形成可辩护根因识别结论的最佳实践
- Separate roles: record the trigger, direct mechanism, contributing conditions, failed prevention controls, detection gaps, and organizational factors independently.区分角色：分别记录触发因素、直接机制、促成条件、预防控制失效、检测缺口和组织因素。
- Preserve alternatives: assign an evidence owner to challenge the leading explanation and document observations that would disconfirm it.保留替代解释：指定证据负责人挑战领先解释，并记录可能推翻它的观察结果。
- Match rigor to consequence: a low-impact repeatable process deviation may need a short analysis; a safety-critical, regulated, or systemic event needs qualified review and stronger evidence.让严谨度匹配后果：低影响且可重复的流程偏差可能只需简短分析；安全关键、受监管或系统性事件需要合格复核和更强证据。
- Connect detection to diagnosis: anomaly alerts and change points identify where investigation should begin, not what caused the event. Continue from detection into evidence-led diagnosis, and use the InfiniSynapse data and analytics blog to review related anomaly-detection topics.连接检测与诊断：异常告警和变点只能说明从哪里开始调查，不能说明事件由什么导致。应从检测继续推进到证据驱动的诊断，并通过 InfiniSynapse 数据与分析博客查看相关异常检测主题。
- Choose tooling after method: when the team needs evidence traceability, assignments, version history, diagrams, and follow-up records, compare the available entry points in the InfiniSynapse Tools directory; do not assume a general analysis workspace is dedicated RCA software.先定方法再选工具：当团队需要证据追踪、任务分配、版本历史、图表和跟进记录时，可在 InfiniSynapse 工具目录中比较可用入口；不要把通用分析工作区假定为专用 RCA 软件。
Frequently asked questions about root cause analysis techniques根因分析技术常见问题
What are the main root cause analysis techniques?主要的根因分析技术有哪些？
Common techniques include 5 Whys, fishbone diagrams, Pareto analysis, fault tree analysis, change analysis, barrier analysis, timelines, and causal-factor mapping. Choose by problem complexity, evidence, risk, and the decision the investigation must support.
常见技术包括五问法、鱼骨图、帕累托分析、故障树分析、变更分析、屏障分析、时间线和因果因素图。应根据问题复杂度、证据、风险以及调查必须支持的决策进行选择。
Which root cause analysis technique should I use first?应该先使用哪种根因分析技术？
Start by defining the problem and building a timeline. Use 5 Whys for a narrow causal chain, fishbone for broad hypothesis generation, Pareto for prioritization, fault trees for interacting logic, and change analysis when a known transition preceded the event.
先定义问题并建立时间线。窄因果链使用五问法，广泛生成假设使用鱼骨图，确定优先级使用帕累托分析，交互逻辑使用故障树；已知变更发生在事件之前时使用变更分析。
Can root cause analysis identify more than one cause?根因分析能否识别多个原因？
Yes. Complex incidents often involve a trigger, enabling conditions, failed controls, and detection gaps. Record their roles separately rather than forcing one item to explain the entire event.
可以。复杂事件通常同时涉及触发因素、促成条件、控制失效和检测缺口。应分别记录它们的角色，不要强迫一个因素解释整个事件。
How do you verify a root cause?如何验证根因？
A cause is supported when it explains the evidence and mechanism, survives tests against alternatives, predicts observations, and leads to a corrective action whose effect can be measured. Recurrence or contradictory evidence should reopen the investigation.
当某个原因能够解释证据与机制、经受替代解释检验、预测观察结果，并导向效果可测量的纠正措施时，它才获得支持。出现复发或矛盾证据时应重新开启调查。
What is the difference between RCA and FMEA?RCA 与 FMEA 有什么区别？
RCA is usually retrospective and investigates why an observed event occurred. FMEA is usually prospective and ranks possible failure modes before an event. Teams may use RCA findings to update an FMEA, but the two activities answer different questions.
RCA 通常是回顾性的，调查已观察到的事件为何发生；FMEA 通常是前瞻性的，在事件发生前对可能的失效模式进行排序。团队可用 RCA 结论更新 FMEA，但两项活动回答不同问题。
Official sources and verification notes官方来源与验证说明
- AHRQ Patient Safety Network root cause analysis primer
- U.S. Department of Education overview of RCA approaches
- CMS Five Whys RCA tool
These sources support the systems-oriented definition, the need to choose methods by context, and the iterative 5 Whys practice. The selection matrix, technique combinations, stopping rules, and pipeline example are editorial synthesis. Verify current primary documentation and organizational requirements before consequential use.
这些来源支持系统导向定义、按情境选择方法以及迭代式五问实践。选择矩阵、技术组合、停止规则和管道示例均为编辑整理；在重要用途前，请核对当前第一方文档与组织要求。