# RISK: Assessment challenges 01, 02, 04, 16, 17

> The five RISK challenges from the practitioner synthesis (01, 02, 04, 16, 17): the scope of safety risk management, translating risk analysis into defensible regulatory decisions, reasonably foreseeable misuse and control effectiveness, unsupported AI-generated assessments, and critical use tasks across overlapping methods. Every challenge (01, 02, 04, 16, 17) includes an AskDona Assessment solution analysis with linked, fact-checked FDA references.

- Status: Current. Last verified 2026-10-15.
- Applies to: Qualitative synthesis of 17 public practitioner discussions, October 2026, with AskDona Assessment solution analyses (15 October 2026). Not facts about AskDona, verified audit findings or prevalence statistics.
- Canonical: https://askdona.com/ai/assessment-challenges-risk.md

**Challenges in this section**

- [01 Defining the scope of safety risk management](#01-defining-the-scope-of-safety-risk-management)
- [02 Translating risk analysis into defensible regulatory decisions](#02-translating-risk-analysis-into-defensible-regulatory-decisions)
- [04 Assessing reasonably foreseeable misuse and control effectiveness](#04-assessing-reasonably-foreseeable-misuse-and-control-effectiveness)
- [16 Preventing plausible but unsupported AI-generated assessments](#16-preventing-plausible-but-unsupported-ai-generated-assessments)
- [17 Identifying critical use tasks across overlapping methods](#17-identifying-critical-use-tasks-across-overlapping-methods)

---

## 01 Defining the scope of safety risk management

**Category: RISK | Subcategory: Product Safety**

Assessment area: Risk Assessment

Medical device teams face difficulties deciding how to document identified failure modes that are assessed as causing no harm or only inconvenience. Excluding such cases from formal risk files may reduce the volume of documentation but can also make it harder to demonstrate that foreseeable failures were evaluated. The challenge is to establish consistent criteria for distinguishing safety risks from usability or business concerns, and to preserve an appropriate rationale for decisions without assuming that every failure mode must appear in the ISO 14971 risk management file.

In the case discussed, the team initially compiled potential failure modes and assessed their possible consequences. Cases classified as involving inconvenience or no patient harm were then removed from the official risk management file, even where engineers implemented design features to address the underlying behavior. This distinction creates a difficult documentation question: a failure mode is not itself a harm, yet the analysis leading to a no-harm conclusion may still be important evidence that a foreseeable sequence of events was considered.

Practitioners disagreed about whether such cases should remain in the formal file. Some favored retaining assessed failure modes to preserve a defensible history of the decision, while others noted that strictly business-related concerns need not be treated as patient safety risks under ISO 14971. The issue is especially pronounced for software functions used in several clinical contexts, because the same technical failure may be harmless in one workflow and significant in another.

The underlying challenge is to define and consistently apply a risk management boundary while preserving the reasoning used to classify and exclude issues. An organization needs to distinguish an appropriately documented no-harm assessment from an unexamined omission, and make clear where non-safety product problems are managed.

---

### AskDona Assessment — Defining the Scope of Safety Risk Management

**Topic:** RISK — Defining the scope of safety risk management

**Status:** Current · verified 2026-10-15 · 01

**Category:** RISK | Subcategory: Product Safety

**Assessment area:** Risk Assessment

**Focus:** Documented no-harm / inconvenience determinations, foreseeable failure modes, ISO 14971 risk-management boundaries, and traceable expert review.

**Source and interpretation note.** Section 1 reproduces the challenge supplied for this topic. Section 2 quotes the supplied English analysis of FDA Warning Letters, not verbatim passages extracted from FDA letters. **[Outdated — marked 2026-10-15]** The case-specific observations and links in Section 8 are sourced from the supplied analysis and should be checked against each FDA document before external publication. **Updated (15 Oct 2026):** all 7 linked FDA letters were opened and each finding checked; the result is given as a “Fact check” note under each finding. FDA Warning Letters concern particular US regulatory findings and do not by themselves establish a universal ISO 14971 rule for every company or device. The solutions below are proposed assessment workflows, not a determination of regulatory compliance or device safety.

#### 1. Original Challenge — Verbatim Source Text

##### 1.1 Summary

Medical device teams face difficulties deciding how to document identified failure modes that are assessed as causing no harm or only inconvenience. Excluding such cases from formal risk files may reduce the volume of documentation but can also make it harder to demonstrate that foreseeable failures were evaluated. The challenge is to establish consistent criteria for distinguishing safety risks from usability or business concerns, and to preserve an appropriate rationale for decisions without assuming that every failure mode must appear in the ISO 14971 risk management file.

##### 1.2 Full original discussion

In the case discussed, the team initially compiled potential failure modes and assessed their possible consequences. Cases classified as involving inconvenience or no patient harm were then removed from the official risk management file, even where engineers implemented design features to address the underlying behavior. This distinction creates a difficult documentation question: a failure mode is not itself a harm, yet the analysis leading to a no-harm conclusion may still be important evidence that a foreseeable sequence of events was considered.

Practitioners disagreed about whether such cases should remain in the formal file. Some favored retaining assessed failure modes to preserve a defensible history of the decision, while others noted that strictly business-related concerns need not be treated as patient safety risks under ISO 14971. The issue is especially pronounced for software functions used in several clinical contexts, because the same technical failure may be harmless in one workflow and significant in another.

The underlying challenge is to define and consistently apply a risk management boundary while preserving the reasoning used to classify and exclude issues. An organization needs to distinguish an appropriately documented no-harm assessment from an unexamined omission, and make clear where non-safety product problems are managed.

##### 1.3 Regulatory and operational interpretation

The decision is not “put every failure mode in the RMF” versus “delete every no-harm item.” It is whether the organization can reconstruct a reasoned assessment of foreseeable sequences of events, device-specific use contexts, potential harms (if any), control measures and the chosen record location. A failure mode, a hazardous situation, a harm, an inconvenience and a non-safety defect are distinct concepts. A documented exclusion can be legitimate; an unexamined omission cannot be treated as equivalent.

#### 2. FDA Warning Letter–Derived Insights — Original Analytical Wording

These passages are reproduced from the user-supplied FDA-derived analysis; they are not represented as direct FDA quotations.

##### 2.1 Unsupported no-risk or cosmetic classifications

A frequent point of failure for medical device teams is identifying a change, a new software function, or a hardware modification, labeling it as "cosmetic" or "no safety risk," and excluding it from formal risk files without rigorous, documented justification [2, 5].

In software updates, regulatory investigators have cited facilities for adding new product requirements (such as expanded patient measurement features) and simply stating in their risk control matrix that "no safety risk [was] identified," without providing any analysis, evaluation, or written justification [2].

##### 2.2 Improvements that may conceal risk controls

The boundary between a "usability enhancement" (often considered a business concern) and a patient safety risk is highly scrutinized. Teams often attempt to separate user-experience modifications from safety controls, which can lead to compliance issues [4].

##### 2.3 Foreseeable omissions and operating conditions

Under-scoping a DFMEA to only a few "high-priority" line items risks omitting foreseeable events [3].

Risk analysis procedures must evaluate foreseeable hazards in both normal and fault conditions, documenting not just the severity of harms but also the probability of occurrence [6].

##### 2.4 Reassessment based on postmarket evidence

Even if a failure mode is initially deemed acceptable or classified as a minor inconvenience, postmarket data can radically shift its risk profile [1].

##### 2.5 Recommendations in the supplied analysis

**Mandate Traceability with Justification:** Implement a quality system procedure that requires strict traceability between all product requirements (including software features) and the risk management matrix [2].

**Document Cosmetic and Usability Changes:** For any Engineering Change Order (ECO) or design alteration deemed "cosmetic" or "non-safety," require a documented risk assessment that directly interfaces with the dFMEA [5].

**Capture Mitigation History:** If engineers implement design level controls to address a failure mode—even if that failure is classified as a mere "inconvenience" or "usability issue"—keep that line item in the FMEA [4, 7].

**Important qualification:** The last recommendation is the supplied analysis's conservative proposal, not an absolute requirement to include every no-harm failure mode in an ISO 14971 RMF. AskDona should help verify why a case is included, cross-referenced to a separate issue log, or excluded from the formal safety file under documented, approved criteria.

**Fact check (15 Oct 2026, against the linked FDA letters):** **The three recommendations are the analysis's own takeaways, not recommendations made in the cited letters.** Traceability between product requirements and risks was Philips' own corrective action [2]; FDA said the firm had not shown traceability for all device risks or defined what an appropriate rationale is. FDA's “cosmetic” criticism in Pensar [5] concerns one ECO, not ECOs generally. Neither Medline [4] nor E-Care [7] says to keep line items in an FMEA (E-Care has no FMEA). In 2.1, the “no safety risk” and “cosmetic” examples are supported by [2] and [5], but no “hardware modification” is described in either (both are software or firmware changes).

#### 3. Detailed Findings and AskDona Assessment Mapping

Each mapping follows the same six-part pattern: (A) FDA-derived original insight, (B) finding, (C) AskDona assessment perspective, (D) proposed solution, (E) expected benefit, (F) capability boundary.

##### Finding 01 — Unsupported “No Safety Risk” Assessments

**FDA-derived original insight (supplied analysis):**

In software updates, regulatory investigators have cited facilities for adding new product requirements (such as expanded patient measurement features) and simply stating in their risk control matrix that "no safety risk [was] identified," without providing any analysis, evaluation, or written justification [2].

**Finding / observation:** A label of “no safety risk” without a traceable analysis does not show what use scenario, hazard or evidence was considered.

**AskDona Assessment perspective:** Treat the reasoning behind a no-harm designation as an assessable evidence requirement, separate from the final risk decision.

**Proposed solution:** Import a criterion requiring the requirement ID, intended-use context, hazardous-situation assessment, cited rationale, approver and record location; review the risk matrix, RMF, software requirements and review minutes using RAG; return evidence-linked Satisfied / Gap / Cannot determine preliminary labels.

**Expected benefit:** Exclusions become more defensible and missing rationales become visible before audit.

**Capability boundary:** Evidence retrieval, configured checklist assessment and citation-based output are established; automatic clinical harm classification is not established.

**Reference:** [[2]](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/royal-philips-709948-09092025).

**Fact check (15 Oct 2026, against the linked FDA letters):** **Partly supported; product details corrected.** Philips [2]: new product requirements were not included in the ISCV Product Safety Risk Management Matrix, the firm concluded “no safety risk [was] identified”, and FDA wrote that “no justification for this conclusion was provided.” The change was the ISCV Version 8.0 release adding fetal measurements and multi-fetus support (version 7.1 supported a single fetus), not general “software updates” or “expanded patient measurement features”, and the “no safety risk” statement appears in Table 1 of the firm's response to FDA's inspection findings (Form 483), not in the risk matrix itself. “Written justification” is not FDA's wording.

##### Finding 02 — “Cosmetic” Changes Without DFMEA Linkage

**FDA-derived original insight (supplied analysis):**

Similarly, characterizing a change—such as an engineering update to reduce system noise—as purely "cosmetic in nature" and unrelated to safety or effectiveness without a documented risk assessment tied to the device's design FMEA (dFMEA) is a major compliance deficiency [5].

**Finding / observation:** A change classification may be a conclusion rather than an analysis.

**AskDona Assessment perspective:** Review classification and supporting change-impact reasoning as separate criteria.

**Proposed solution:** Compare ECOs, change justifications, DFMEA references, affected requirements and verification results; flag absent risk review or unresolved effect on adjacent functions.

**Expected benefit:** Reduces silent exclusions and enables consistent change-review evidence packages.

**Capability boundary:** Document-level matching is achievable where records are supplied; automated end-to-end ECO/PLM impact propagation requires integration/design validation.

**Reference:** [[5]](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/lion-street-medical-dba-pensar-medical-llc-733015-08212026).

**Fact check (15 Oct 2026, against the linked FDA letters):** **Partly supported.** Pensar Medical [5]: FDA objects to the firm's characterization of a “(b)(4) noise change” as “cosmetic in nature” and unrelated to safety or effectiveness, made “without a documented risk assessment tied to the device's design FMEA.” The change was a WoundPro+ firmware update under ECO 25-039; its purpose is redacted, so “to reduce system noise” is not stated. The letter also notes that no WoundPro FMEAs of any type existed. “Major compliance deficiency” is the analysis's wording.

##### Finding 03 — Usability “Enhancements” May Address Safety-Relevant Failures

**FDA-derived original insight (supplied analysis):**

For instance, dimensional modifications to device parts (such as piston syringes) intended to "improve user experience" by reducing the chance of cracks or plunger pullouts have been argued by manufacturers to be "improvements" rather than risk mitigations [4].

**Finding / observation:** Describing a correction as an improvement does not establish that its underlying failure is safety-neutral.

**AskDona Assessment perspective:** Assess the reported failure and potential sequence of events independently of the ECO title.

**Proposed solution:** Search complaints, CAPA, usability records, ECOs, risk files and verification reports for evidence of loss of essential performance or foreseeable harms; flag mismatches between “enhancement” labels and observed failure descriptions.

**Expected benefit:** Better integration of field experience into safety-boundary decisions.

**Capability boundary:** Preliminary text-based inconsistency identification is possible; interpretation of safety significance remains with qualified experts.

**Reference:** [[4]](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/medline-industries-lp-677545-03182024).

**Fact check (15 Oct 2026, against the linked FDA letters):** **Partly supported.** Medline [4]: dimensional changes to piston syringes were made, in the firm's words, “to improve the user experience by reducing the chance for cracked syringes and plunger pullout”, and management called it “an improvement and enhancement”, not a risk mitigation. FDA's findings were that the risk assessment did not adequately address the identified hazards (cracked syringes, plunger pullout), no new risks were assessed, no user validation was done and the DFMEA was not updated. The “boundary … is highly scrutinized” framing is the analysis's own.

##### Finding 04 — Foreseeable Failure Modes Removed Without a Reviewable History

**FDA-derived original insight (supplied analysis):**

Under-scoping a DFMEA to only a few "high-priority" line items risks omitting foreseeable events [3].

**Finding / observation:** A sparse formal file might reflect justified scope or incomplete hazard identification; the absence of a line item alone does not distinguish them.

**AskDona Assessment perspective:** Evaluate coverage and documented dispositions, not only whether an RMF row exists.

**Proposed solution:** Use a master failure-mode/issue register and criteria mapping to RMF, design review, usability issue log or other controlled records; assess whether each selected excluded case has a retained rationale and owner.

**Expected benefit:** Preserves traceable exclusion history without automatically inflating the formal RMF.

**Capability boundary:** Existing checklist evidence review is supported; automated creation of a complete failure-mode inventory is a proposed workflow, not a guaranteed product function.

**Reference:** [[3]](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/unilam-co-ltd-738562-09222026).

**Fact check (15 Oct 2026, against the linked FDA letters):** **Partly supported.** Unilam [3]: the DFMEA “only addresses 4 risk line items”, and its limited scope means it fails “to include reasonably anticipated failure modes” (for example chemical exposure if the lamp breaks); risk controls rely almost entirely on labeling. The letter does not say the items were chosen as “high-priority”; that is the analysis's wording.

##### Finding 05 — Foreseeable Conditions and Residual-Risk Justifications

**FDA-derived original insight (supplied analysis):**

Even if these are eventually added retrospectively, failing to identify specific design mitigations or to explain how the overall residual risk was deemed acceptable is inadequate [7].

**Finding / observation:** Retrospectively adding an event does not itself supply risk-control traceability or a reasoned acceptance decision.

**AskDona Assessment perspective:** Require a chain from foreseeable event → hazardous situation → harm (where applicable) → control → verification → residual-risk rationale.

**Proposed solution:** Run item-level assessments against DFMEA, RMF, requirements, testing, and design reviews; identify missing links and ambiguous references in the exported report.

**Expected benefit:** More reviewable safety conclusions and clearer remediation priorities.

**Capability boundary:** The system can assemble evidence and preliminary gaps; it does not validate a risk calculation or independently approve residual risk.

**Reference:** [[7]](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/e-care-technology-corp-605117-03022020).

**Fact check (15 Oct 2026, against the linked FDA letters):** **Partly supported.** E-Care Technology [7]: the firm updated its Risk Management Report to include specific potential failure modes, but “there are no risk mitigations noted” and it is “unclear how you have determined that the overall residual risk is acceptable.” The failure modes were added in the firm's response to the inspection, not described as “retrospective”; FDA says “risk mitigations”, not “design mitigations”; and the letter concerns a Risk Management Report, not an FMEA.

##### Finding 06 — Normal Use and Fault Conditions Considered Unevenly

**FDA-derived original insight (supplied analysis):**

Risk analysis procedures must evaluate foreseeable hazards in both normal and fault conditions, documenting not just the severity of harms but also the probability of occurrence [6].

**Finding / observation:** A blanket “no harm” classification may be context-dependent, particularly for software used in multiple clinical workflows.

**AskDona Assessment perspective:** Define separate assessment units by clinical use, user, operational state and failure condition.

**Proposed solution:** Configure prior questions and document metadata to select device/version/use scenario; evaluate normal-use and fault-condition evidence separately; label unsupported scenario claims Cannot determine.

**Expected benefit:** Fewer false cross-context assumptions and more targeted expert review.

**Capability boundary:** Pre-question filters and RAG scoping are documented existing features; dynamic hazard scenario generation and fully automated applicability determination remain subject to validation.

**Reference:** [[6]](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/xoran-technologies-llc-694229-12092024).

**Fact check (15 Oct 2026, against the linked FDA letters):** **Partly supported; attribution corrected.** In Xoran [6], “foreseeable hazards in both normal and fault conditions” and “probability of occurrence of harm and severity” come from the **firm's own Risk Management procedure (SOP 39, section 9.3)**, which FDA found was not implemented: the Hazards and Harms Matrix documented only the severity of harms, not their probability of occurrence. The cited regulation (21 CFR 820.30(g)) does not contain this wording, so “risk analysis procedures must …” should read as the firm's procedural requirement, not an FDA rule. The letter also cites 29 DFMEA items with blank recommended actions and residual risk not re-evaluated since 2011.

##### Finding 07 — Postmarket Signals Change Earlier No-Harm Judgments

**FDA-derived original insight (supplied analysis):**

Even if a failure mode is initially deemed acceptable or classified as a minor inconvenience, postmarket data can radically shift its risk profile [1].

**Finding / observation:** A classification may need reconsideration when actual complaints, usage patterns or severity evidence change.

**AskDona Assessment perspective:** Treat past exclusion decisions as reviewable conclusions with reassessment triggers, not permanent facts.

**Proposed solution:** Include periodic checklist criteria confirming review of updated complaint/PMS datasets against earlier risk assumptions, conclusions and approvals; export missing-evidence and potential discrepancy findings for expert action.

**Expected benefit:** Earlier identification of outdated no-harm rationales and better closed-loop risk review.

**Capability boundary:** Periodic manual/triggered re-execution is possible using current assessment workflows; automated continuous monitoring, impact analysis and deterministic delta re-assessment are not assumed to be generally released.

**Reference:** [[1]](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/onkos-surgical-inc-712573-07212025).

**Fact check (15 Oct 2026, against the linked FDA letters):** **Partly supported.** Onkos [1] (ELEOS Limb Salvage System): the firm did not use the real complaint rates of loosening (3.27%, 0.149% and 3.1%) to update the occurrence rating in its risk table, unchanged since 1 April 2019. FDA: an updated postmarket rate “changes the failure mode from an acceptable risk to a conditionally acceptable risk”, which requires evaluating additional risk controls under the firm's SOP. The failure mode was rated acceptable, not described as a “minor inconvenience”, and “radically shift its risk profile” overstates a change from acceptable to conditionally acceptable.

##### 3.8 Cross-cutting interpretation of the seven findings

<div class="table-scroll">

| Regulatory risk pattern | What AskDona should check | What AskDona must not decide autonomously |
| :--- | :--- | :--- |
| Unjustified exclusion | Whether scope, evidence, decision rationale and approver are recorded | Whether absence of harm is scientifically established |
| Unclear boundary | Whether safety, usability and business concerns have distinct documented dispositions | Whether every engineering issue belongs in an ISO 14971 RMF |
| Incomplete traceability | Whether event, clinical context, risk control and tests are connected | Whether every mitigation is sufficient |
| Misleading change labels | Whether ECO terminology conflicts with complaints and technical facts | Final safety/regulatory impact of the change |
| Changing PMS evidence | Whether old assumptions have been compared with new evidence | Final risk acceptability and market action |

</div>

#### 4. Suggested Operating Model — Risk Boundary Assessment

**Step 1 — Define the assessment unit.** Record device and software version, intended use, clinical workflow, user/patient population and normal/fault condition. Avoid transferring a “no harm” conclusion from one scenario to another without explicit justification.

**Step 2 — Preserve the initial universe of issues.** Retain a controlled master list of proposed failure modes and observed issues even where selected items are ultimately handled outside the formal safety RMF. The master list may live in an issue register, design-control or quality system, subject to the organization’s approved procedures.

**Step 3 — Establish expert-authored criteria.** Set clear rules for what constitutes a safety-related hazard/hazardous situation, harm, inconvenience, usability concern or business-only issue. Define evidentiary requirements and approval authority for inclusion, cross-reference and exclusion. Expert teams—not AskDona—set regulatory applicability and the criteria.

**Step 4 — Assemble evidence.** Load controlled RMF/DFMEA versions, hazard analyses, requirements, software architecture, ECOs, usability studies, verification/validation data, CAPA and complaint/PMS records into the permitted evidence repository. Preserve version and effective-date metadata.

**Step 5 — Run evidence-based preliminary assessments.** For each criterion, AskDona returns a preliminary result, reason, quoted evidence and source file; a missing document should normally lead to an evidence insufficiency / cannot-determine outcome, not an automatic finding of regulatory noncompliance.

**Step 6 — Human safety and regulatory review.** A qualified reviewer determines inclusion/exclusion, records rationale, verifies cited passages against the authoritative source, approves the disposition and places the signed decision in the controlled QMS/RMF or linked record.

**Step 7 — Reassess at defined triggers.** Re-run relevant checks after clinically relevant software changes, new use settings, complaints, field safety signals or applicable procedural updates. A fully automated change-impact engine would require separate implementation and validation.

#### 5. Example Assessment Criteria for an AskDona Pilot

The following are proposed criteria, not off-the-shelf regulatory requirements or confirmed built-in AskDona templates.

<div class="table-scroll">

| ID | Example assessment criterion | Evidence to inspect | Preliminary failure / uncertainty trigger |
| :--- | :--- | :--- | :--- |
| RM-01 | Every sampled “no harm” determination names the device function and use scenario. | RMF, issue log, clinical workflow description | Scenario absent or ambiguous |
| RM-02 | The analysis differentiates failure mode, sequence of events, hazardous situation and harm, or explains why no hazardous situation arises. | Hazard analysis, DFMEA, review minutes | Unsupported “no risk” assertion |
| RM-03 | The evidence includes foreseeable normal and fault conditions relevant to the sampled case. | Risk procedure, use scenarios, risk reviews | Only one condition considered without rationale |
| RM-04 | Each excluded safety candidate has an approved rationale and identified controlled record location. | Disposition log, QMS approval, RMF linkage | Disposition untraceable |
| RM-05 | Where a design change addresses a reported failure, change-impact review considers whether it was a risk control. | ECO, CAPA, complaints, DFMEA | “Enhancement only” without supporting analysis |
| RM-06 | Referenced risk controls have corresponding implementation and verification evidence when applicable. | Design specifications, test reports | Control/test linkage cannot be established |
| RM-07 | The exclusion rationale has been reviewed for all declared clinical contexts of a shared software function. | Product configurations, risk reviews | Context coverage uncertain |
| RM-08 | Recent complaint/PMS information has been considered when reassessing the original classification. | PMS reports, trend reviews, RMF revisions | Assumptions not revisited following relevant new data |
| RM-09 | Non-safety issues excluded from the RMF are managed in an identifiable process or register. | Issue tracker, usability log, complaint procedure | Unclear handoff or ownership |
| RM-10 | The final boundary decision is approved by the designated qualified personnel. | Approval record, review history | Only an AI preliminary result or informal note exists |

</div>

**Illustrative output:** Criterion: RM-04 | Preliminary label: Cannot determine | Reason: An exclusion decision is mentioned but its approval and controlled record location were not found in the supplied evidence | Evidence: [verbatim excerpt] | Source: [controlled document/version] | Human action: Locate the disposition record and confirm the approved RMF boundary.

#### 6. AskDona Capability and Evidence Boundaries

<div class="table-scroll">

| Capability / claim | Status based on the supplied AskDona materials | Appropriate wording in a customer proposal |
| :--- | :--- | :--- |
| Import assessment criteria from Excel | Documented existing Batch Assessment functionality | Configure a risk-boundary checklist from expert-defined criteria. |
| Retrieve evidence from an RAG repository | Documented existing | Find relevant passages from the documents in the selected repository. |
| Output preliminary label, explanation, quotation and referenced file | Documented existing | Prepare traceable first-pass reviews for expert approval. |
| Prior questions, metadata filtering and exclusion of inapplicable criteria | Documented existing | Scope assessments to a device or context where metadata and rules are configured. |
| Return “Cannot determine” on insufficient evidence | Configurable existing label approach | Escalate unproven assertions instead of forcing a yes/no conclusion. |
| Reliably determine clinical harm, risk acceptability or reportability | Not established; requires expert judgment | Do not claim autonomous medical or regulatory conclusions. |
| Generate complete ISO 14971 hazard coverage automatically | Not established | Treat AI-assisted issue discovery as a proposed use case requiring testing. |
| Automatically sync ECO/CAPA/PMS changes across QMS/PLM | Integration concept / scope-dependent | Subject to product integration, access controls and validation. |
| Deterministic end-to-end repeated assessments | Demonstrated in a specific research pipeline and conditions; broader deployment not established | Research evidence supports feasibility, not universal production behavior. |

</div>

The supplied AskDona knowledge summary positions assessment as Criteria → Evidence → Preliminary Assessment → Human Review, with expert final responsibility. It reports a security assessment proof of concept with 91%+ accuracy and 45% effort reduction in that specific context, which must not be advertised as achieved for ISO 14971 risk assessment. It also distinguishes production functionality from research and roadmap proposals.

#### 7. Proposed Pilot and Outcome Measures

##### 7.1 Pilot design

- **Scope:** One device family or a shared software feature used in two clinical contexts; 20–40 sampled failure modes including (a) formal RMF entries, (b) documented no-harm exclusions, (c) usability-only issues and (d) ambiguous cases.
- **Participants:** Risk management, clinical/safety engineering, software/design, QA and regulatory reviewers. A qualified person defines the expected results before model evaluation.
- **Evidence:** Controlled RMF, DFMEA, ECOs, usability records, test reports, complaint/PMS samples and applicable SOPs; use deliberate missing-evidence cases to test abstention.
- **Execution:** Experts define ~10 criteria, run AskDona first-pass assessments, inspect each source quotation and compare with blinded expert adjudication.
- **Deliverable:** Criterion-level gap table with evidence source, reason, final human disposition, remediation owner and record destination.

##### 7.2 Success measures (pilot targets to define, not proven outcomes)

<div class="table-scroll">

| Measurement | What to measure | Desired impact |
| :--- | :--- | :--- |
| Evidence retrieval quality | Relevant, verifiable quotations / sampled criteria | Less manual source hunting |
| Rationale coverage | Proportion of sampled exclusions with a complete approved rationale | Fewer unexamined omissions |
| False assurance | Proportion of unsupported no-harm claims incorrectly labeled satisfied | Minimize misleading conclusions |
| Context discrimination | Cases where conclusions differ appropriately between clinical contexts | More precise boundaries |
| Expert review effort | Minutes per case versus current manual baseline | Lower administrative burden |
| Traceability completeness | Cases with explicit source/version and disposition location | Stronger audit readiness |
| Reassessment readiness | Time to identify old decisions needing review after new PMS/ECO records | Faster controlled follow-up |

</div>

##### 7.3 Expected organizational benefits

A successful, validated deployment could reduce repetitive evidence search, standardize the format of no-harm rationales, preserve a reviewable history of exclusions, clarify where non-safety issues are governed and focus specialist time on disputed safety judgments. These are prospective benefits, not quantified performance claims for this use case. Adoption should include documented intended use, role-based access, output review and appropriate software assurance.

#### 8. FDA Warning Letter References — Full, Copy-Persistent URLs

**[Outdated — marked 2026-10-15]** The numbered references below follow the user-supplied FDA-derived analysis, not an independent verification of the precise findings. **Updated (15 Oct 2026):** all 7 linked FDA letters were opened and each finding checked; the result is given as a “Fact check” note under each finding. Firm names, letter numbers and dates match, and all seven are CDRH device letters. Several statements attributed to FDA are the firms' own procedures or corrective actions (Philips traceability, Xoran SOP 39, Onkos SOP-008). These are FDA Warning Letters, and each link is written as a complete URL so that copying the entire Markdown text preserves its destination.

1. [1] [Onkos Surgical, Inc. — 712573 — 07/21/2025](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/onkos-surgical-inc-712573-07212025). Postmarket occurrence-rate information and updates to risk evaluations.<br/>https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/onkos-surgical-inc-712573-07212025
2. [2] [Royal Philips — 709948 — 09/09/2025](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/royal-philips-709948-09092025). Unsupported “no safety risk” assessments and requirement/risk traceability.<br/>https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/royal-philips-709948-09092025
3. [3] [Unilam Co., LTD — 738562 — 09/22/2026](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/unilam-co-ltd-738562-09222026). Scope and completeness of anticipated failures in risk analysis.<br/>https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/unilam-co-ltd-738562-09222026
4. [4] [Medline Industries, LP — 677545 — 03/18/2024](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/medline-industries-lp-677545-03182024). Product changes described as improvements and their relationship to observed failures.<br/>https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/medline-industries-lp-677545-03182024
5. [5] [Lion Street Medical, d/b/a Pensar Medical LLC — 733015 — 08/21/2026](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/lion-street-medical-dba-pensar-medical-llc-733015-08212026). Cosmetic change rationales and documented DFMEA assessment.<br/>https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/lion-street-medical-dba-pensar-medical-llc-733015-08212026
6. [6] [Xoran Technologies, LLC — 694229 — 12/09/2024](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/xoran-technologies-llc-694229-12092024). Risk analysis under relevant use and fault conditions.<br/>https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/xoran-technologies-llc-694229-12092024
7. [7] [E-Care Technology Corp. — 605117 — 03/02/2020](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/e-care-technology-corp-605117-03022020). Risk-control evidence, hazard identification and residual-risk reasoning.<br/>https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/e-care-technology-corp-605117-03022020

**Positioning statement:** AskDona Assessment can support the distinction between a justified “no harm” decision and an unexamined omission by checking whether expert-defined safety-boundary criteria are supported by traceable, reviewable evidence. It helps prepare decisions; it does not replace qualified ISO 14971 risk-management judgment.

---

## 02 Translating risk analysis into defensible regulatory decisions

**Category: RISK | Subcategory: Product Safety**

Assessment area: Risk Assessment

Risk assessments require more than listing possible problems. Regulatory teams must determine potential consequences, assess likelihood and severity where appropriate, examine available controls, and communicate residual uncertainty to decision-makers. In practice, the analytical burden increases when supporting evidence is incomplete or different stakeholders interpret the same risk differently. A structured rationale is necessary to make decisions reproducible and understandable.

Risk-related judgments arise across regulatory projects, including proposed product changes, submissions, and communications with management. The difficulty is not simply calculating a score; the assessor must identify the decision being made, gather sufficiently reliable information, evaluate credible outcomes, and explain how uncertainty affects the recommendation. A technically sound analysis can still be ineffective if stakeholders cannot understand the assumptions on which the conclusion rests.

Teams may use different definitions of significance, or approach the same issue from distinct manufacturing, clinical, quality, and regulatory perspectives. Without a shared assessment method, the result can depend disproportionately on who performs the evaluation. Reviewers may also challenge a conclusion if supporting evidence is scattered across email, development reports, and prior decisions rather than linked to the final assessment.

The central challenge is to make professional risk judgments reproducible and explainable, while recognizing that some regulatory decisions necessarily remain contextual rather than mechanically determined.

---

### AskDona Assessment — Translating Risk Analysis into Defensible Regulatory Decisions

**As of:** October 15, 2026  
**Category:** RISK | **Subcategory:** Product Safety  
**Assessment area:** Risk Assessment  
**Focus:** Evidence-grounded risk decisions, analytical consistency, residual uncertainty, postmarket reassessment, and qualified human oversight.

> **Interpretation and quotation note:** Section 1 reproduces the challenge provided for this assessment area verbatim. The passages labeled **“FDA-derived insight — original analytical wording”** in Section 3 reproduce relevant sentences from the supplied analysis of FDA Warning Letters; they are **not verbatim quotations from the Warning Letters themselves**. The linked FDA letters provide underlying case context. This document describes a proposed risk-assessment workflow and does not claim that AskDona makes final clinical, regulatory, recall, or risk-acceptability decisions.

#### 1. Original Challenge — Verbatim

##### Translating risk analysis into defensible regulatory decisions

**Current · verified 2026-10-15**  
**02**  
**Category: RISK | Subcategory: Product Safety**  
**Assessment area: Risk Assessment**

> Risk assessments require more than listing possible problems. Regulatory teams must determine potential consequences, assess likelihood and severity where appropriate, examine available controls, and communicate residual uncertainty to decision-makers. In practice, the analytical burden increases when supporting evidence is incomplete or different stakeholders interpret the same risk differently. A structured rationale is necessary to make decisions reproducible and understandable.
>
> Risk-related judgments arise across regulatory projects, including proposed product changes, submissions, and communications with management. The difficulty is not simply calculating a score; the assessor must identify the decision being made, gather sufficiently reliable information, evaluate credible outcomes, and explain how uncertainty affects the recommendation. A technically sound analysis can still be ineffective if stakeholders cannot understand the assumptions on which the conclusion rests.
>
> Teams may use different definitions of significance, or approach the same issue from distinct manufacturing, clinical, quality, and regulatory perspectives. Without a shared assessment method, the result can depend disproportionately on who performs the evaluation. Reviewers may also challenge a conclusion if supporting evidence is scattered across email, development reports, and prior decisions rather than linked to the final assessment.
>
> The central challenge is to make professional risk judgments reproducible and explainable, while recognizing that some regulatory decisions necessarily remain contextual rather than mechanically determined.

#### 2. Overall Assessment and AskDona Positioning

##### Regulatory observation

A defensible risk decision requires an explicit **decision question**, appropriate and current **evidence**, documented **assumptions**, assessment of relevant **probability/severity and controls**, transparent treatment of **unknowns**, and an identifiable **qualified reviewer/decision owner**. A numerical score alone does not prove that the underlying assumptions, denominator, control effectiveness, or decision threshold are justified.

##### AskDona Assessment perspective

AskDona Assessment is best positioned as an **evidence-based preliminary assessment and review engine**, rather than an autonomous risk-rating or regulatory-decision engine. Experts define the applicable criteria and approved risk methodology; AskDona searches a designated evidence repository, checks the supplied documents against each criterion, and returns a **preliminary label, rationale, quoted evidence, and referenced file**. Qualified personnel verify the evidence, resolve uncertainty, and make and record the final decision in the organization's controlled quality or regulatory process.

##### Proposed operating principle

**Expert-defined decision and criteria → relevant controlled evidence → AskDona preliminary evidence assessment → unresolved gaps and assumptions → cross-functional expert review → approved regulatory decision and controlled record.**

The solution particularly addresses **document-intensive, repetitive evidence verification**. It does not independently validate statistical models, calculate a clinically valid probability of harm, decide regulatory applicability, or establish risk acceptability.

#### 3. FDA-Derived Findings Mapped to AskDona Assessment

Each finding below includes (1) original analytical wording, (2) regulatory finding, (3) AskDona perspective, (4) offered or proposed solution, and (5) expected adoption benefit.

##### Finding 01 — Risk calculations and assumptions can understate patient harm

**FDA-derived insight — original analytical wording:**

> Underestimating the probability of harm can lead to disastrous regulatory delays. In one notable case, an incorrect risk calculation formula underestimated the probability of occurrence of harm associated with failed retainer rings in insulin infusion pumps [18].

**Finding / regulatory issue:** The reported risk classification can be unreliable when the underlying probability denominator, exposure assumptions, formula, or consequence categories are inappropriate. The Medtronic Warning Letter discusses a risk formula that underestimated probability and affected field-action decisions.

**AskDona Assessment perspective:** Evaluate the **documentation and consistency of the risk method**, not simply whether a score exists. Distinguish a mathematical calculation check from a scientifically defensible risk decision.

**AskDona solution:** Configure criteria requiring identification of the applicable risk SOP/version, probability formula, population or exposure denominator, harm categories, source data, matrix thresholds, and reviewer justification. Use document retrieval to compare the risk report, SOP, health hazard evaluation, CAPA/complaint records, and decision memorandum. Generate preliminary **Satisfied / Gap / Cannot determine** findings with cited excerpts and source filenames. Where quantitative recalculation is required, route it to a validated calculation process and a qualified expert rather than treating AskDona's text-based assessment as a validated calculator.

**Expected benefit:** Earlier visibility into unsupported assumptions, inconsistent calculation approaches, and apparently low-risk conclusions lacking adequate explanation; a clearer evidence package for review and inspection.

**FDA case link:** [Medtronic, Inc. — Warning Letter 617539 (Dec. 9, 2021)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/medtronic-inc-617539-12092021).

**Fact check (15 Oct 2026, against the linked FDA letters):** **Supported, except the opening sentence.** Medtronic (MiniMed 600 series insulin pumps): the firm's “risk calculation formula underestimated the probability of occurrence of harm” for the failed retainer rings, in a June 2016 risk assessment and health hazard evaluation used to inform field-action decisions; with the risk rated low there was no correction or removal until the November 2019 recall. FDA also criticised counting total shipments (including devices not in use) and questioned the mortality-based calculation. The formula's terms are redacted, and “disastrous regulatory delays” is the analysis's wording.

##### Finding 02 — Risk scales and residual-risk evaluations are applied inconsistently

**FDA-derived insight — original analytical wording:**

> Risk rating tables must be used consistently. Discrepancies between the probability levels defined in a firm's standard operating procedures (SOPs) and those utilized in Health Hazard Evaluations (HHEs) represent a major compliance failure [15].

> Risk analyses must explicitly document how identified risks are being controlled post-mitigation. Leaving recommended action fields blank or failing to calculate post-mitigation risk values (e.g., Risk = Probability × Severity) for critical line items in Design Failure Mode and Effects Analyses (DFMEAs) signals to regulators that further controls were never seriously considered [16].

**Finding / regulatory issue:** Different scales, missing control-action entries, omitted verification, or unrecorded post-control assessments make it difficult to reconstruct why residual risk was accepted. The cited formula is illustrative, **not a universal ISO 14971 or regulatory formula**.

**AskDona Assessment perspective:** Assess a documented chain of **hazard or failure → potential harm → pre-control estimate (when applicable) → control decision → implementation and verification evidence → residual-risk rationale → approval**.

**AskDona solution:** Import expert-authored checklist items from Excel. Check risk SOPs, DFMEA/RMF tables, HHEs, test reports, design reviews, and change records against each criterion. Flag inconsistent terminology, missing post-control assessments, or absent evidence references through preliminary findings. Require human review of risk methodology and control sufficiency. Use version-specific metadata to prevent confusing outdated and current matrices.

**Expected benefit:** More consistent risk-review preparation; fewer unexplained or incomplete risk-control records; reduced manual effort gathering evidence for risk acceptance reviews.

**FDA case links:** [iRhythm Technologies — Warning Letter 643474 (May 25, 2023)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/irhythm-technologies-inc-643474-05252023) · [Xoran Technologies — Warning Letter 694229 (Dec. 9, 2024)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/xoran-technologies-llc-694229-12092024).

**Fact check (15 Oct 2026, against the linked FDA letters):** **iRhythm: supported; Xoran: partly supported.** iRhythm (Zio AT): mainly in footnotes, FDA notes the Health Risk Table defined by SOP0010 was not used in the HHE, several probability levels did not correspond to the SOP, and the miscalculation underestimated the likelihood of injury (correctly calculated, the risk would have been “Medium”). Xoran: about 29 FMEA line items with a post-mitigation risk priority of “B” had a blank “Recommended Action” field, and the Hazards and Harms Matrix documented severity but not probability of occurrence. Post-mitigation priorities were in fact recorded, “critical” line items is not FDA's wording, and **no letter states Risk = Probability × Severity**; the formula is the analysis's illustration.

##### Finding 03 — Postmarket evidence can invalidate previously accepted assumptions

**FDA-derived insight — original analytical wording:**

> If postmarket complaint data reveals that a failure mode is occurring at a rate higher than originally estimated, the risk table must be updated. For example, failing to adjust the occurrence rating for stem implant loosening based on real-world complaint rates of 3.1% to 3.27% (while keeping the historical risk table locked at a much lower percentage) prevents the risk from appropriately transitioning from "acceptable" to "conditionally acceptable" [1].

**Finding / regulatory issue:** A risk decision is not defensible indefinitely merely because its original analysis was approved. New complaint rates, adverse-event patterns, service records, or product modifications may undermine the original likelihood or control-effectiveness assumptions. The numbers and acceptability labels above are **case-specific**, not universal thresholds.

**AskDona Assessment perspective:** Treat prior risk judgments as **reviewable, evidence-dependent conclusions** with predefined reassessment triggers and assigned owners.

**AskDona solution:** Configure periodic or event-triggered **manual reruns** of the checklist after new complaint datasets, trend reports, CAPA records, or RMF versions have been loaded. Check whether updated occurrence evidence was considered, whether prior assumptions remain documented, and whether a competent reviewer reevaluated risk. Highlight missing reassessment records or inconsistencies as candidate review items. Automatic continuous monitoring and deterministic change-impact reassessment would require additional implementation and validation.

**Expected benefit:** Faster identification of risk decisions potentially made obsolete by field evidence and better preparation of controlled reassessment packages.

**FDA case link:** [Onkos Surgical — Warning Letter 712573 (July 21, 2025)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/onkos-surgical-inc-712573-07212025).

**Fact check (15 Oct 2026, against the linked FDA letters):** **Partly supported.** Onkos (ELEOS Stem Implant Risk Table): the firm did not use complaint-derived loosening rates of 3.27%, 0.149% and 3.1%, from three separate complaints rather than a 3.1–3.27% range, to update an occurrence rating that “remains unchanged” since 1 April 2019 (the value is redacted). FDA: the update “changes the failure mode from an acceptable risk to a conditionally acceptable risk”, requiring evaluation of additional risk controls under the firm's SOP-008. “Locked” and “prevents … transitioning” are the analysis's wording.

##### Finding 04 — Narrow evidence selection hides clinically relevant outcomes

**FDA-derived insight — original analytical wording:**

> When evaluating postmarket clinical failures, risk teams often define search criteria too narrowly. If a firm only searches for specific terms like "osteolysis" and excludes associated failure modes or clinical symptoms such as joint subluxation, instability, subsidence, migration, or pain, the resulting risk assessment will be based on incomplete evidence and fail to capture the true clinical impact [3].

**Finding / regulatory issue:** Risk conclusions can appear rigorous even when their evidence population omits related symptoms, failure modes, affected product configurations, or use conditions. A negative search is not equivalent to proof that no adverse outcome exists.

**AskDona Assessment perspective:** Examine **evidence coverage and search scope** as explicit assessment criteria; separate what the available documents support from what remains unsearched, unavailable, or uncertain.

**AskDona solution:** Have experts specify relevant event groups, synonyms, device versions, use populations, and review periods. Apply structured metadata and pre-assessment questions to scope the repository and evaluate whether investigation reports show that the specified categories were considered. Return **Cannot determine** where the supplied record does not establish coverage. Automated exhaustive synonym discovery or assurance that all relevant evidence has been retrieved is not a proven existing capability.

**Expected benefit:** More transparent investigation boundaries, fewer unsupported negative conclusions, and clearer questions for clinical/quality review.

**FDA case link:** [Exactech, Inc. — Warning Letter 669904 (Jan. 19, 2024)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/exactech-inc-669904-01192024).

**Fact check (15 Oct 2026, against the linked FDA letters):** **Partly supported; details corrected.** Exactech (Equinoxe shoulder implants): the HHE search was not limited to “osteolysis”; it included polyethylene wear, osteolysis, poly component fracture and disassociation, and the data used covered only polyethylene wear (11 complaints/MDRs). The listed symptoms (instability, subluxation, loss of range of motion, subsidence, migration, pain, dislocation) are harms from the **firm's own Risk Assessment and Controls Report**, which FDA quotes; FDA's finding is that the HHE search criteria “do not encompass failure modes identified” in that report, and that the raw data supporting the assessment could not be provided.

##### Finding 05 — Weak evidence and absence of complaints are mistaken for safety assurance

**FDA-derived insight — original analytical wording:**

> A defense based primarily on "no complaints received" is inadequate when the underlying manufacturing process or visual inspection controls have drifted out of a state of control [13].

> Because of the nature of contamination events, the lowest or highest results from a small sample size cannot reveal the true range of minimum and maximum contamination levels in a batch [5].

**Finding / regulatory issue:** Sparse sampling, retrospective testing, or the absence of reported harm can leave material uncertainty unresolved. These examples include pharmaceutical/manufacturing cases and should be used as **cross-sector lessons about evidence quality**, not as medical-device-specific rules.

**AskDona Assessment perspective:** Explicitly assess the **strength, limitations, and missing elements** of the documented rationale rather than equating an available test result with adequate assurance.

**AskDona solution:** Create criteria for sampling-plan justification, method qualification/validation where applicable, investigation scope, contradictory observations, recognized limitations, and uncertainty disclosure. Search supporting reports and procedures and output reasoned preliminary gaps or **Cannot determine** when the evidence is insufficient. Scientific assessment of sampling adequacy, contamination risk, or product release stays with specialists.

**Expected benefit:** Better visibility of residual uncertainty, more focused scientific reviews, and clearer communication to decision-makers about what the evidence does and does not establish.

**FDA case links:** [Pine Pharmaceuticals — Warning Letter 728537 (Aug. 7, 2026)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/pine-pharmaceuticals-llc-728537-08072026) · [Signature Formulations — Warning Letter 718093 (Jan. 21, 2026)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/signature-formulations-llc-718093-01212026).

**Fact check (15 Oct 2026, against the linked FDA letters):** **Pine: partly supported; Signature: supported.** Pine Pharmaceuticals (a 503B compounding outsourcing facility, CDER) found risk assessments “outcome-based, focusing primarily on the absence of complaints or adverse events” and used as a substitute for corrective action, after batches were released despite exceeding critical defect limits; the exact phrase “no complaints received” and “drifted out of a state of control” are not in the letter. Signature Formulations (OTC toothpaste and mouthwash, CDER Office of Manufacturing Quality; not compounding): “the lowest or highest results obtained from testing a small sample size” are unlikely to reveal the true range, because contamination is generally non-uniformly distributed.

##### Finding 06 — Product-change and risk-control decisions lack traceability

**FDA-derived insight — original analytical wording:**

> To prevent reviewers from challenging risk-related decisions, firms must implement clear traceability between product requirements, identified risks, and assigned risk control IDs within an updated Risk Management Matrix [4].

> A robust risk analysis requires the integration of manufacturing, quality, clinical, and regulatory viewpoints. Without centralized oversight, professional judgments become siloed and inconsistent.

**Finding / regulatory issue:** Different functions may rely on different documents or assumptions. When a product change, software requirement, risk-control ID, verification result, and risk decision are not linked, the organization may be unable to explain the decision across disciplines or to an inspector.

**AskDona Assessment perspective:** Make the **minimum evidence and rationale required for cross-functional review explicit**, and distinguish evidence completeness from final clinical/regulatory approval.

**AskDona solution:** Define criteria covering change scope, affected requirement IDs, potential harms, risk-control references, verification/validation evidence, alternative explanations, remaining uncertainty, final approver, and record destination. Assess ECOs, requirements, risk matrices, development reports, clinical/quality reviews, and decision minutes in a curated repository. Export item-level preliminary results, commentary, quoted passages, and source filenames to Excel for review and inclusion in existing QMS/PLM processes. Direct, automated integrations require separately specified and validated development.

**Expected benefit:** A common review structure across teams, less time reconstructing decisions from scattered files, and more understandable explanations for management, auditors, and regulators.

**FDA case link:** [Royal Philips — Warning Letter 709948 (Sept. 9, 2025)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/royal-philips-709948-09092025).

**Fact check (15 Oct 2026, against the linked FDA letters):** **Not supported as an FDA requirement.** In Philips (ISCV software), traceability between product requirements and risks, and assigning a risk control ID in an updated Risk Management Matrix, were the **firm's own corrective actions**; FDA's finding was that the updated matrix had not been provided to verify that traceability, that new requirements were missing from the ISCV risk matrix, and that the “no safety risk” conclusion had no justification. The cross-functional integration sentence is the analysis's own; it is not cited to a letter.

#### 4. Proposed AskDona Assessment Configuration

The following is a **suggested customer-specific template**, not a claim that a complete medical-device risk-decision template ships with the product.

<div class="table-scroll">

| Criterion ID | Expert-defined assessment question | Evidence to inspect | Preliminary gap or uncertainty condition |
|---|---|---|---|
| RD-01 | Is the exact decision, affected product/version, intended use and decision owner identified? | Change request, product specification, risk review | Decision boundary or owner absent |
| RD-02 | Are applicable risk methodology, likelihood/severity definitions, scoring thresholds and SOP versions identified? | Risk SOP, risk plan, HHE/RMF | Ambiguous or incompatible scales |
| RD-03 | Are key probability assumptions, denominators, exposure period and supporting data explained? | Risk calculation, field-use data, complaints | Critical assumptions or sources missing |
| RD-04 | Are reasonably foreseeable harms and relevant use/fault conditions addressed, or exclusions justified? | Hazard analysis, clinical/usability reports | Relevant scenario coverage unsupported |
| RD-05 | Are required controls, implementation/verification, and post-control risk decisions traceably linked? | RMF/DFMEA, control IDs, test reports | Broken control-to-evidence chain |
| RD-06 | Are evidence limitations, alternative explanations and residual uncertainty explicitly acknowledged? | Investigation report, method validation, sampling rationale | Overconfident conclusion from limited data |
| RD-07 | Are relevant postmarket signals and changed assumptions reflected in the current risk review? | Complaints, PMS, CAPA, risk revisions | Current data not reconciled with prior conclusion |
| RD-08 | Have manufacturing, quality, clinical and regulatory viewpoints been considered as required by the organization's procedure? | Review minutes, comments, approval records | Required participation or rationale absent |
| RD-09 | Is the conclusion supported by specific citations and an identified authoritative document/version? | Final risk report, source documents | Supporting evidence cannot be located |
| RD-10 | Is the final decision approved and retained in the designated controlled system? | QMS approval record, decision log | No responsible human approval evident |

</div>

**Recommended output labels:** `Satisfied` / `Gap` / `Not applicable` / `Cannot determine`, with definitions configured for the specific workflow. In particular, **a document not found is not, by itself, proof of regulatory noncompliance**.

**Illustrative first-pass output** (fictional):

```text
Criterion: RD-03
Preliminary label: Cannot determine
Reason: The risk evaluation identifies an occurrence category but the supplied
       documents do not establish whether the denominator represents devices
       actively used by patients during the evaluation period.
Evidence: [exact passage from the controlled risk report, if located]
Source file: [document name / version]
Reviewer question: Confirm the exposure denominator, supporting dataset,
                   methodology, and effect on the risk decision.
Final disposition: Pending qualified expert review.
```

#### 5. What AskDona Can Provide — With Clear Capability Boundaries

<div class="table-scroll">

| Capability | Status supported by supplied materials | Contribution to this risk-decision workflow |
|---|---|---|
| Excel import of predefined assessment items | **Documented existing functionality** | Standardize expert-approved criteria across assessments |
| RAG-based document search and preliminary criterion-level evaluation | **Documented existing functionality** | Reduce manual evidence searching across uploaded controlled documents |
| Preliminary label, comment, quoted evidence, referenced filename | **Documented existing functionality** | Make the grounds of each preliminary conclusion reviewable |
| Pre-assessment questions, metadata filtering and rule-based exclusion of inapplicable items | **Documented existing functionality** | Scope reviews by device/version, project or document category when configured |
| Excel export and stored execution history | **Documented existing functionality** | Prepare structured review files for existing quality/regulatory processes |
| Expert-controlled decision and review | **Required operating principle** | Keep safety, clinical, regulatory and risk-acceptability responsibility with qualified personnel |
| Fully automated risk calculation and scientific validation of probability/severity estimates | **Not established** | Requires appropriate validated calculations and expert oversight |
| Automatic generation of complete risk criteria, applicability, and hazard coverage | **Proposed / not established as a general production capability** | Requires expert-defined criteria and separate validation |
| Automated real-time QMS/PLM/complaint-system synchronization | **Integration strategy / dependent on implementation** | Not assumed available as an out-of-the-box feature |
| End-to-end byte-identical assessment reproduction and deterministic impact analysis | **Demonstrated in a constrained research pipeline; not established for every commercial deployment** | Potential longer-term assurance/change-control capability, not a blanket production claim |

</div>

##### Reproducibility: an important but separate dimension

The supplied October 2026 research draft reports that **none of 13 tested commercial LLM deployments reproduced the entire preliminary assessment for every prompt**, and **11 changed at least one assessment label**. A research pipeline designed to control document extraction, OCR, chunking, embeddings, retrieval and inference produced byte-identical records in defined medical-device experiments. That result demonstrates *technical feasibility under the tested configuration*, **not proof that the conclusions were accurate, compliant, or that all commercial AskDona deployments now exhibit such determinism**. Risk-decision reproducibility must be assessed separately from scientific correctness, evidence relevance and human decision quality.

#### 6. Recommended Implementation Workflow

1. **Define the intended use and decision types.** Select a bounded pilot, such as design-change risk reviews or periodic re-evaluation of residual-risk documentation; specify which decisions remain entirely outside the AI workflow.
2. **Approve criteria and labels.** Risk, quality, clinical and regulatory experts define the checklist, evidence expectations, meaning of each label, and escalation conditions.
3. **Curate the repository.** Load controlled SOPs, RMF/DFMEA versions, HHEs, ECOs, verification records, complaints, CAPA, and review minutes; apply device/version/effective-date metadata.
4. **Configure the assessment.** Import the Excel checklist; configure pre-questions, filters, label definitions, output mapping and a conservative instruction to return `Cannot determine` when evidence is insufficient.
5. **Pilot and validate for the intended use.** Compare against independently reviewed sample cases, including conflicting or missing evidence. Check quotation accuracy, missed gaps, inappropriate `Satisfied` results, inter-run stability and review effort.
6. **Review and approve.** Experts examine source passages, resolve uncertainties, validate calculations and record the final rationale and authorized decision in the controlled system of record.
7. **Maintain and reassess.** Establish triggers for reruns after relevant design changes, risk-procedure updates and field data, together with assessment-version management and human approval.

#### 7. Expected Benefits and Suggested Pilot KPIs

<div class="table-scroll">

| Expected benefit | Why it matters | Pilot measurement (not a promised outcome) |
|---|---|---|
| Reduced evidence-assembly effort | Experts spend less time locating risk SOPs, controls, tests and prior decisions | Minutes spent searching per risk decision |
| Better rationale completeness | Missing assumptions, denominator explanations, controls and approvals become visible | Percentage of sampled decisions satisfying approved evidence criteria |
| More consistent assessments | The same approved criteria are applied across teams and products | Inter-reviewer disagreement; consistency of preliminary results |
| Greater visibility of uncertainty | Insufficient evidence is escalated rather than converted into unjustified certainty | False-`Satisfied` rate; `Cannot determine` handling quality |
| Clearer audit and management communication | Each preliminary conclusion has a reason and supporting source | Percentage of cited quotations independently verifiable |
| More disciplined postmarket reassessment | Prior conclusions can be checked against newly supplied records | Time to prepare postmarket-triggered reassessment packages |
| Stronger expert governance | Final clinical and regulatory decisions remain with accountable personnel | Percentage of final decisions carrying documented human approval |

</div>

A separately reported security-assessment proof of concept cited **91%+ answer accuracy and 45% reduction in assessment effort** in its specific setting. These figures **must not be generalized to medical-device risk management or used as forecasted benefits here**. The pilot should establish its own baseline and success criteria.

#### 8. Conclusion

**AskDona Assessment can help convert fragmented risk documentation into structured, evidence-linked preliminary evaluations that qualified professionals can explain, challenge and approve.** Its most defensible value is not autonomous risk scoring; it is checking whether the organization's expert-defined decision criteria are supported by identifiable evidence, highlighting missing or contradictory rationales, and preparing a consistent review package. Where the decision depends on scientific estimation, clinical significance, regulatory interpretation or residual-risk acceptability, the final judgment remains explicitly human.

#### 9. FDA Warning Letter URLs — Copyable Markdown Links

The following links correspond to the **selected illustrative FDA cases**, not an exhaustive list of all cases in the supplied example analysis. The document intentionally uses full URLs so links remain copyable when the `.md` file is reused.

- [Medtronic, Inc. — 617539 — Dec. 9, 2021](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/medtronic-inc-617539-12092021)
- [iRhythm Technologies, Inc. — 643474 — May 25, 2023](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/irhythm-technologies-inc-643474-05252023)
- [Xoran Technologies, LLC — 694229 — Dec. 9, 2024](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/xoran-technologies-llc-694229-12092024)
- [Onkos Surgical, Inc. — 712573 — July 21, 2025](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/onkos-surgical-inc-712573-07212025)
- [Exactech, Inc. — 669904 — Jan. 19, 2024](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/exactech-inc-669904-01192024)
- [Pine Pharmaceuticals, LLC — 728537 — Aug. 7, 2026](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/pine-pharmaceuticals-llc-728537-08072026)
- [Signature Formulations, LLC — 718093 — Jan. 21, 2026](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/signature-formulations-llc-718093-01212026)
- [Royal Philips — 709948 — Sept. 9, 2025](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/royal-philips-709948-09092025)

**Link and quotation caveat:** FDA links are supplied for traceability and copying. The quoted *analytical insights* above come from the supplied example analysis rather than the FDA letter text, and should not be published as direct FDA quotations. FDA Warning Letters describe particular observations, rather than establishing a universal risk-scoring formula or a device-independent compliance conclusion.

**Fact check (15 Oct 2026, against the linked FDA letters):** all 8 letters were opened at the linked FDA pages; firm names, letter numbers and dates match, and the result for each finding is given as a “Fact check” note under it. Six are CDRH device letters; Pine Pharmaceuticals (503B outsourcing facility) and Signature Formulations (OTC drugs) are CDER drug letters. The bracketed numbers inside the quoted insights ([18], [15], [16], [1], [3], [13], [5], [4]) follow the supplied analysis's own numbering, not this list.

---

## 04 Assessing reasonably foreseeable misuse and control effectiveness

**Category: RISK | Subcategory: Product Safety**

Assessment area: Risk Assessment

Safety assessment must consider not only the intended use of a device but also reasonably foreseeable misuse, including use of non-specified accessories. The challenge is to identify credible hazardous situations, determine whether labeling alone sufficiently reduces risk, and justify when technical or design-based controls are warranted. Such decisions need product-specific evidence rather than assumptions about user compliance.

The charging example illustrates a general difficulty in safety assessment: products can be used with accessories, environments, or workflows outside the manufacturer's preferred configuration. Teams need to consider which departures from intended use are reasonably foreseeable and whether they can give rise to hazardous situations. This assessment requires more than noting that instructions prohibit a particular behavior.

Where a non-specified accessory might affect electrical or thermal behavior, reviewers must evaluate potential consequences, the likelihood of exposure, and the reliability of available risk controls. They may need to examine product architecture, physical compatibility, protective circuitry, information for safety, and relevant verification evidence. The assessment can become contentious if one function assumes that labeling ends the analysis while another expects a design-level safeguard.

The operational challenge is to connect foreseeable-use scenarios to technically justified controls and evidence of effectiveness, without treating either all imaginable misuse or warning language as an automatic answer.

---

### AskDona Assessment — Assessing Reasonably Foreseeable Misuse and Control Effectiveness

**Status:** Current · verified 2026-10-15 · 04  
**Category:** RISK | **Subcategory:** Product Safety  
**Assessment area:** Risk Assessment  
**Focus:** Foreseeable misuse, non-specified accessories, design-level risk controls, labeling, operational environments, and evidence-based effectiveness review.

> **Source integrity and regulatory qualification:** Section 1 reproduces the provided challenge verbatim. Section 2 reproduces selected *original wording from the supplied FDA-related analysis*, not verbatim quotations independently extracted from FDA Warning Letters or inspection guidance. **[Outdated — marked 2026-10-15]** The URLs are preserved as supplied and are not represented as independently verified quotations. **Updated (15 Oct 2026):** all 9 linked FDA pages were opened and each insight and finding checked; the result is given as a “Fact check” note. Some FDA materials concern specific firms or non-device industries; their observations are illustrative and must not be applied automatically as universal medical-device rules. All solutions described below are assessment-support workflows, not automated regulatory determinations.

#### 1. Original Challenge — Verbatim

##### 1.1 Title and context

**Assessing reasonably foreseeable misuse and control effectiveness**  
**Current · verified 2026-10-15 · 04**  
**Category: RISK | Subcategory: Product Safety**  
**Assessment area: Risk Assessment**

##### 1.2 Original text

> Safety assessment must consider not only the intended use of a device but also reasonably foreseeable misuse, including use of non-specified accessories. The challenge is to identify credible hazardous situations, determine whether labeling alone sufficiently reduces risk, and justify when technical or design-based controls are warranted. Such decisions need product-specific evidence rather than assumptions about user compliance.
>
> The charging example illustrates a general difficulty in safety assessment: products can be used with accessories, environments, or workflows outside the manufacturer’s preferred configuration. Teams need to consider which departures from intended use are reasonably foreseeable and whether they can give rise to hazardous situations. This assessment requires more than noting that instructions prohibit a particular behavior.
>
> Where a non-specified accessory might affect electrical or thermal behavior, reviewers must evaluate potential consequences, the likelihood of exposure, and the reliability of available risk controls. They may need to examine product architecture, physical compatibility, protective circuitry, information for safety, and relevant verification evidence. The assessment can become contentious if one function assumes that labeling ends the analysis while another expects a design-level safeguard.
>
> The operational challenge is to connect foreseeable-use scenarios to technically justified controls and evidence of effectiveness, without treating either all imaginable misuse or warning language as an automatic answer.

##### 1.3 Core assessment question

**Can a qualified reviewer reconstruct why a particular departure from intended use was considered reasonably foreseeable (or not), what hazardous situation it could produce, which risk controls were selected, and what product-specific evidence supports their effectiveness and residual-risk conclusion?**

The assessment must distinguish evidence of *an instruction or warning being present* from evidence that the *risk has been adequately controlled*. The former does not, by itself, establish the latter.

#### 2. FDA Warning Letter–Derived Insights — Original Analytical Wording

The following are **verbatim excerpts from the supplied analysis**. Bracketed numbers retain the supplied reference numbering (see Section 8). They are **not direct quotations from the FDA documents**.

##### 2.1 Labeling versus design-level safeguards

> A frequent deficiency in product risk management is an over-reliance on instructions and warnings rather than physical or software design safeguards. Regulatory evaluations establish that labeling is generally not adequate to prevent adverse events on its own [2]. Instead, device labeling should only supplement robust design and testing to address unavoidable precautions that users must take despite the implementation of design-level controls [2].

> When a manufacturer relies almost entirely on warning language or delegates critical risk-mitigation steps to downstream operators or end-users, they fail to demonstrate that residual risks have been brought to an acceptable level [4]. For example, physical hazards, such as the foreseeable risk of chemical exposure in the event of lamp breakage, require design-level mitigations within the manufacturing process rather than simple warnings [4].

**Fact check (15 Oct 2026, against the linked FDA pages):** **Unilam [4] partly supported.** FDA found risk controls “rely almost entirely on labeling” or on actions only the downstream sunlamp-bed manufacturer can take, preferred design-level controls within the firm's own manufacturing process, and found residual risk not shown to be acceptable. The letter refers to a downstream manufacturer, not end users, and it notes only that the DFMEA omits chemical exposure from lamp breakage; it does not say that hazard specifically requires design-level mitigation. [2] and [6] are checked under Findings 01 and 02.

> Furthermore, when evaluating user errors or maladaptive behaviors, safety assessments must distinguish between simple user training deficiencies and underlying system design flaws [6]. Implementing corrective actions that focus exclusively on training and labeling improvements, without evaluating whether the device's user interface or alert systems contributed to the user's maladaptive behavior, represents an inadequate approach to risk control [6].

##### 2.2 Actual environments and operational overrides

> **Environmental Divergence:** A manufacturer's design assumptions regarding the use environment often differ from reality [8]. For instance, a device may be subjected to unexpected electromagnetic disturbances (EMD) because a user lives near high-power transmission lines [8]. Manufacturers must not disregard erratic, unexpected behaviors that "self-resolve" or cannot be reproduced in a controlled laboratory; instead, they should evaluate whether incorrect environmental assumptions compromised the device's built-in shielding or filtering [8].

> **Operational Overrides:** Foreseeable misuse also includes active operator departures from established procedures. Software designs must anticipate that operators may attempt to override automated sequences, edits, or safety stops (such as reactivating an ingredient auger motor even when a weigh scale exceeds its critical limit) [9]. Such capabilities necessitate thorough validation of computer control parameters rather than assuming operators will always follow standard workflows [9].

##### 2.3 Accessories and interoperability

> **Interacting Components:** When introducing changes to products or components that physically interact with a primary system, manufacturers must conduct dedicated validation and retrospective design impact assessments rather than assuming prior testing of standard sizes covers the new configurations [1].

**Fact check (15 Oct 2026, against the linked FDA pages):** **Happiest Baby [1] partly supported.** For two new SNOO sleep-sack sizes (X-Small and X-Large), the firm relied on prior testing of the Small, Medium and Large sacks, and FDA disagreed; the Leg Lifters accessory was also not adequately validated with the current sleep sack. The “retrospective design impact assessment” of all interacting products was the **firm's own** corrective-action commitment, not an FDA requirement. [7] and [5] are checked under Findings 05 and 06.

> **Accessory-Induced Hazards:** Marketing or utilizing unapproved accessory devices can severely compound existing risks. For example, using non-specified accessories with medical syringes can cause technological failures, leading to physical cracking, leakage, contamination, and critical dose inaccuracies [7].

> **Labeling and Reprocessing Integrity:** In convenience kits where individual finished components are combined, a failure to include original labeling can lead to patient harm due to the incorrect use or storage of individual items [5]. Additionally, repeated sterilization of finished components to facilitate reuse can degrade physical materials and negatively impact the fit, form, and function of the device [5].

##### 2.4 Postmarket evidence and reassessment

> To ensure safety assessments remain objective and technically justified, manufacturers must dynamically update their risk evaluations using product-specific post-market data. Design validation procedures must establish a continuous mechanism to collect and report post-market feedback—such as customer complaints, clinical literature, and competitor database trends [6]. This feedback must be assessed against original risk profiles to determine whether new, unrecognized failure modes have occurred or if the real-world rate of occurrence has changed, which mathematically alters risk acceptability and necessitates new design-level safeguards [3, 6].

**Interpretation safeguard:** These passages are analytical generalizations in the supplied material. They do not mean that every foreseeable misuse mandates an additional engineering control, that labeling can never be an appropriate control, or that third-party accessory use automatically falls within the same scope for every device. Control selection and residual-risk acceptance remain product-, context-, and evidence-dependent decisions made by qualified personnel.

#### 3. Regulatory Findings, AskDona Perspective, Solutions, and Expected Benefits

Each finding uses the same four analytical fields: **Finding**, **AskDona Assessment perspective**, **Proposed solution**, and **Expected benefit**. A fifth field distinguishes product capability from expert responsibility.

##### Finding 01 — Labeling is mistaken for proof of effective risk reduction

**FDA-derived insight (original):**
> A frequent deficiency in product risk management is an over-reliance on instructions and warnings rather than physical or software design safeguards. Regulatory evaluations establish that labeling is generally not adequate to prevent adverse events on its own [2].

**Finding / observation:** A risk file may list a warning, instruction, or training activity as a mitigation but provide no documented assessment of alternative design controls, human reliance, or control effectiveness.

**AskDona Assessment perspective:** Treat **control selection**, **implementation**, **verification of effectiveness**, and **residual-risk rationale** as separate, evidence-testable criteria. The presence of a warning is one evidence element, not a complete conclusion.

**Proposed AskDona solution:** Configure a risk-control checklist covering (a) hazardous situation and associated harm, (b) design or protective controls considered, (c) reasons for retaining information-for-safety measures, (d) test/usability evidence, and (e) residual-risk justification. Compare expert-defined criteria against the risk-management file (RMF), risk-control matrix, design specifications, labeling, human-factors studies, and verification reports. Return a preliminary label, explanation, source quotations, and cited files for each criterion.

**Expected benefit:** Greater visibility of warning-only justifications and stronger evidence packages for design-control decisions, while allowing documented context-specific choices.

**Capability boundary:** Evidence retrieval and item-level preliminary review are documented capabilities. AskDona does **not** independently determine whether a warning is legally sufficient or approve risk acceptability.

**Fact check (15 Oct 2026, against the linked FDA pages):** **Partly supported.** The EMC inspection guide [2] says “labeling in place of design controls usually is not adequate to prevent adverse events” and that labeling should supplement EMC design and testing. “Only” and “unavoidable precautions” are the analysis's words, and the statement comes from an EMC-specific section of a 2014 FDA inspection guide, so applying it to all labeling is the analysis's generalization.

##### Finding 02 — User errors are attributed to training without investigating design contributors

**FDA-derived insight (original):**
> Implementing corrective actions that focus exclusively on training and labeling improvements, without evaluating whether the device's user interface or alert systems contributed to the user's maladaptive behavior, represents an inadequate approach to risk control [6].

**Finding / observation:** A complaint or use error may be closed as “operator error,” leaving interface ambiguity, alerts, workflow design, and foreseeable behavior inadequately assessed.

**AskDona Assessment perspective:** Require evidence of *system-related causation review* in addition to records of retraining or revised labeling.

**Proposed AskDona solution:** Evaluate criteria for root-cause hypotheses, user-interface design reviews, alarms, usability validation, CAPA rationale, and post-correction testing. Retrieve relevant passages from complaint investigations, software requirements, HFE/usability files, CAPA, change records, and test reports. Flag assessments where only training completion is evidenced while design-related questions remain unresolved.

**Expected benefit:** More complete investigation narratives, fewer unsupported “use error only” conclusions, and clearer prioritization of human-factors or design follow-up.

**Capability boundary:** Cross-document evidence review is supported where information is available to the selected repository; automatic causal diagnosis or HFE adequacy determination is **not** established.

**Fact check (15 Oct 2026, against the linked FDA pages):** **Supported, with attribution notes.** Beta Bionics [6] (iLet dosing software and pump): FDA found the root-cause analysis “fails to distinguish between system design issues versus user training deficiencies”, preventive actions focused solely on training, and asked whether the user interface, alert systems or other design issues contributed. “Maladaptive behaviors” describes the **firm's own** root-cause conclusion as FDA summarized it, and the corrective actions were training and information materials rather than labeling as such.

##### Finding 03 — Idealized environmental assumptions are carried into real-world safety conclusions

**FDA-derived insight (original):**
> A manufacturer's design assumptions regarding the use environment often differ from reality [8].

**Finding / observation:** Electromagnetic, physical, thermal, or workflow conditions outside an ideal laboratory configuration may be dismissed without checking whether they are reasonably foreseeable or whether protective design features were tested under relevant conditions.

**AskDona Assessment perspective:** Make environment and configuration explicit parameters of the assessment, and test the documented linkage between environmental assumptions, hazard analysis, mitigation, and verification.

**Proposed AskDona solution:** Use pre-assessment questions and document metadata to select device/version/use environment; assess explicitly defined scenarios against environmental specifications, hazard analyses, electromagnetic compatibility (EMC) evidence when relevant, service records, complaints, and validation reports. Return **Cannot determine** where the evidence does not address the proposed scenario.

**Expected benefit:** Better differentiation between tested and untested real-world conditions; fewer unsupported assumptions carried into residual-risk review.

**Capability boundary:** Input-flow questions, metadata scoping, and configurable uncertainty labels are documented. Automatically generating complete environmental scenarios or proving technical performance is not established.

**Fact check (15 Oct 2026, against the linked FDA pages):** **Partly supported; example misread.** The EMC guide page [8] uses a **hypothetical** example: a powered-wheelchair maker should not assume users never live near high-power transmission lines or TV antennas. No real device or user is described. The page does say malfunctions that seem to “self-resolve” or cannot be reproduced should not be disregarded as possible EMI, and that shielding can fail when based on incorrect environmental use assumptions; its instruction is to determine the actual use environment.

##### Finding 04 — Operational overrides or bypasses are not represented in risk-control validation

**FDA-derived insight (original):**
> Software designs must anticipate that operators may attempt to override automated sequences, edits, or safety stops (such as reactivating an ingredient auger motor even when a weigh scale exceeds its critical limit) [9].

**Finding / observation:** The documented workflow assumes procedural compliance, while actual operator permissions or system states may permit bypassing an interlock or protective sequence.

**AskDona Assessment perspective:** Distinguish **procedural prohibition** from **technically enforced prevention**; check the specific failure/override path rather than inferring safety from an SOP.

**Proposed AskDona solution:** Create assessment items for override permissions, fail-safe states, access control, alarm behavior, state transitions, verification of interlocks, and deviation handling. Compare control specifications, software requirements, validation protocols, incident logs, and change records; highlight missing test evidence for an explicitly defined foreseeable override.

**Expected benefit:** Improved traceability from misuse scenario to technical safeguard and test result; stronger cross-functional review of operator-dependent controls.

**Capability boundary:** The food-processing example is an illustrative control-system analogy, **not** a medical-device-specific FDA finding. AskDona cannot execute system safety tests or establish software validation merely by reviewing documents.

**Fact check (15 Oct 2026, against the linked FDA pages):** **Partly supported; details corrected.** The food-processing computerized-systems guide [9], written for FDA investigators, does describe software that lets an operator “override the stop and reactivate the auger motor”, but the limit in that example is a weigh-scale **set point**, not a critical limit, and the guide tells investigators to find out what overrides are allowed and how they are documented rather than stating that designs “must anticipate” overrides. It does say the system should be validated in its entirety. It is a food-industry guide, as the capability boundary above notes.

##### Finding 05 — Non-specified accessories and changed configurations are not assessed as distinct hazards

**FDA-derived insight (original):**
> Using non-specified accessories with medical syringes can cause technological failures, leading to physical cracking, leakage, contamination, and critical dose inaccuracies [7].

**Finding / observation:** A safety conclusion for the standard accessory or configuration may be inappropriately extrapolated to foreseeable third-party components, connector dimensions, electrical loads, charging arrangements, or reuse conditions.

**AskDona Assessment perspective:** Treat accessory compatibility and interaction as a **scenario-specific evidence question**. Distinguish a non-specified accessory being prohibited in labeling from documented evaluation of credible use and effects.

**Proposed AskDona solution:** For expert-selected accessory/configuration pairs, check whether the RMF considers mechanical, electrical, thermal, interoperability, contamination, and performance consequences as applicable; whether interface requirements and architecture identify relevant safeguards; and whether testing, investigation, or a justified scope exclusion exists. Retrieve evidence from compatibility matrices, interface specifications, design files, complaint records, verification reports, and labeling.

**Expected benefit:** More defensible compatibility decisions and earlier detection of unsupported extension of validation evidence to new configurations.

**Capability boundary:** AskDona does not simulate an accessory, compute failure physics, or classify all third-party accessories as foreseeable. Experts must define credible combinations, mechanisms, and acceptance standards.

**Fact check (15 Oct 2026, against the linked FDA pages):** **Not supported as framed.** Sol-Millennium [7] concerns the **firm's own** syringe accessories (four models) marketed without 510(k) clearance, a change in intended use; it does not describe users fitting non-specified accessories. FDA does warn that “unsupported accessory device claims may lead to patient harm”, including breakage, leaking, contamination and dose inaccuracy. The phrase “marketing or utilizing unapproved accessory devices” is not in the letter, “cracking” comes from separate complaint findings, and “critical” dose inaccuracies is the analysis's word.

##### Finding 06 — Packaging, labeling transfer, and reprocessing introduce overlooked interactions

**FDA-derived insight (original):**
> In convenience kits where individual finished components are combined, a failure to include original labeling can lead to patient harm due to the incorrect use or storage of individual items [5]. Additionally, repeated sterilization of finished components to facilitate reuse can degrade physical materials and negatively impact the fit, form, and function of the device [5].

**Finding / observation:** Safety evaluation of a component in its original configuration may fail to address changed instructions, kit composition, sterilization exposure, or physical compatibility after reprocessing.

**AskDona Assessment perspective:** Assess whether configuration changes have a documented safety impact review and applicable verification evidence, independently of their description as convenience, packaging, or processing changes.

**Proposed AskDona solution:** Compare kits' bills of materials and labeling records, applicable component instructions, sterilization/reprocessing validation, engineering changes, and RMF revisions using configured checklist criteria. Highlight source gaps and conflicting use or reuse instructions for expert review.

**Expected benefit:** More systematic assessment of secondary configuration effects and better cross-referencing of packaging, reprocessing, and design-control records.

**Capability boundary:** This is document-based preliminary review; technical validity of sterilization or material compatibility testing must be established separately.

**Fact check (15 Oct 2026, against the linked FDA pages):** **Partly supported.** Centurion Medical Products [5] (sterile convenience kits): failure to include appropriate labeling, including the components' original labeling, may cause patient harm through incorrect or unsafe use or storage; repeated sterilization of finished components may speed material degradation and affect form, fit and function. The letter does **not** mention reuse: the context is re-sterilizing already-sterile purchased components when the finished kit is sterilized.

##### Finding 07 — Postmarket evidence does not trigger reconsideration of earlier misuse and control assumptions

**FDA-derived insight (original):**
> This feedback must be assessed against original risk profiles to determine whether new, unrecognized failure modes have occurred or if the real-world rate of occurrence has changed, which mathematically alters risk acceptability and necessitates new design-level safeguards [3, 6].

**Finding / observation:** Initial risk assumptions may persist despite new complaints, unforeseen configurations, field failures, or evidence that a warning-based control did not prevent occurrence.

**AskDona Assessment perspective:** Treat risk-control effectiveness and foreseeability judgments as reviewable conclusions with explicit reassessment triggers, not static declarations.

**Proposed AskDona solution:** Configure periodic or change-triggered assessments of designated risks against updated complaint summaries, CAPA, field reports, postmarket reviews, and revised RMF records. Identify contradictory evidence, absent re-review, and undocumented changes in assumptions. Export evidence-linked exceptions for human adjudication and controlled QMS follow-up.

**Expected benefit:** Faster identification of safety conclusions that merit expert reassessment and more systematic feedback from field experience into design and risk management.

**Capability boundary:** Re-running existing configured assessments is supported. Continuous automated surveillance, automatic ingestion from every QMS, statistically valid rates, and production-grade delta/change-impact analysis are **not** established as generally available features.

**Fact check (15 Oct 2026, against the linked FDA pages):** **Partly supported; the quoted sentence's ending is not FDA's.** Onkos [3]: an updated loosening occurrence rate (complaint rates of 3.27% and 3.1%, rating unchanged since April 2019) “changes the failure mode from an acceptable risk to a conditionally acceptable risk”, pointing to additional risk controls. Beta Bionics [6]: FDA found post-market risks (for example around 529 leak complaints) missing from the risk analysis. The listed feedback sources such as published literature and competitor information come from the **firm's own SOP**, “competitor database” is not in the letter, and “mathematically alters risk acceptability and necessitates new design-level safeguards” appears in neither letter.

#### 4. Recommended AskDona Assessment Operating Model

<div class="table-scroll">

| Step | Activity | Responsible party | AskDona role |
|---|---|---|---|
| 1 | Define the device, version, intended uses, relevant users, foreseeable-use scenarios, and assessment boundary. | Risk-management and clinical/design experts | Capture configured questions and constrain evidence retrieval by metadata. |
| 2 | Define explicit criteria for foreseeability, hazards, risk-control hierarchy, effectiveness evidence, and residual-risk justification. | Qualified experts | Import predefined criteria from Excel; apply configured decision rules. |
| 3 | Assemble controlled evidence: RMF/FMEA, architecture, accessory/interface specifications, labeling, usability/HFE, EMC and other verification, complaints, ECO/CAPA. | Document owners / quality team | Search the selected RAG repository for relevant evidence. |
| 4 | Run criterion-by-criterion first-pass review for each chosen scenario. | Assessment operator | Produce preliminary label, reason, verbatim evidence excerpt, and source file. |
| 5 | Investigate gaps, conflicting records, omitted scenarios, and insufficient proof of control effectiveness. | Cross-functional reviewers | Surface candidate gaps and **Cannot determine** outcomes, without pretending absence of retrieved evidence establishes noncompliance. |
| 6 | Judge foreseeability, harm, risk reduction, remaining uncertainty, and risk acceptability; record final approval. | Authorized safety/quality/regulatory personnel | Supply review material; final sign-off stays in the controlled system of record. |
| 7 | Revisit the assessment upon changes, failures, new accessories, new environments, or postmarket signals. | Process owner | Re-run selected criteria; any full automated change-impact workflow requires separate implementation and validation. |

</div>

**Suggested preliminary labels:** `Satisfied` (specific evidence supports the defined documentation criterion), `Gap / Not satisfied` (evidence demonstrates the criterion is unmet), `Cannot determine` (evidence is incomplete, conflicting, or unavailable), and `Not applicable` (an expert-approved scope rule applies). These are **configured assessment labels, not FDA safety classifications**.

##### Why this matters for the charging/accessory example

For a device charged using a non-specified power accessory, an expert could define review criteria for connector compatibility, supply-voltage and current tolerance, protective circuitry, abnormal thermal conditions, misuse likelihood, accessible warnings, and relevant verification tests. AskDona would **check whether supplied documents substantiate those criteria and quote the evidence**. It would **not** conclude from “use only the supplied charger” that risk is adequately reduced, nor automatically decide that all alternate chargers require redesign.

#### 5. Proposed Pilot Assessment Criteria

These criteria are **examples to configure**, not verified prepackaged product content or independently established regulatory requirements.

<div class="table-scroll">

| ID | Proposed assessment criterion | Evidence to inspect | Escalation / uncertainty trigger |
|---|---|---|---|
| FM-01 | The assessed misuse scenario specifies product version, accessory/configuration, user, environment, and foreseeable interaction. | RMF, intended-use analysis, use-scenario log | Scenario lacks product-specific context. |
| FM-02 | The documented analysis distinguishes misuse event, hazardous situation, potential harm, and plausible event sequence. | Hazard analysis, FMEA, review minutes | “Prohibited use” is the only explanation. |
| FM-03 | The selection of warnings versus engineering/protective controls is justified against documented alternatives. | Risk-control matrix, design review, labeling | Warning is listed without control-selection rationale. |
| FM-04 | Relevant design-based safeguards are traceable to implementation requirements and verification. | Architecture, requirements, V&V, control register | No implementation/test linkage. |
| FM-05 | The evidence addresses effectiveness of information-for-safety or training controls where relied upon. | HFE/usability, comprehension studies, IFU validation | Only distribution of a warning is evidenced. |
| FM-06 | Foreseeable operator overrides or bypass states have been evaluated where technically possible. | Software hazard analysis, access-control specs, tests | SOP compliance assumed without examining bypass paths. |
| FM-07 | Actual or plausible environmental exposure has been reconciled with design and test assumptions. | Environmental requirements, EMC/thermal tests, complaints | Relevant real-world condition not assessed. |
| FM-08 | Non-specified accessories or modified configurations are addressed by a justified assessment boundary and compatibility evidence. | Interface specs, accessory matrix, RMF, verification | Standard-accessory tests assumed to cover others. |
| FM-09 | Packaging, kit assembly, labeling transfer, and reprocessing changes are assessed where applicable. | Labeling records, packaging specifications, validation | Missing component instruction or validation linkage. |
| FM-10 | Recent relevant complaints or field signals were considered in control-effectiveness and occurrence assumptions. | PMS, complaint/CAPA trends, risk review | New signals with no documented reassessment. |
| FM-11 | The residual-risk rationale identifies supporting evidence, limitations, and unresolved uncertainty. | RMF, review decision, acceptance criteria | Conclusion asserts “acceptable” without supporting analysis. |
| FM-12 | The final disposition and any actions are recorded and approved by designated personnel. | QMS approvals, change record, action tracker | AI result or informal correspondence is the only decision record. |

</div>

**Illustrative first-pass record:**

```text
Assessment item: FM-04 — Design safeguard traceability
Preliminary result: Cannot determine
Comment: The hazard analysis identifies overheating under a non-specified power input, but the supplied evidence does not establish that the protective shutdown function was verified for the evaluated configuration.
Evidence: [exact verified excerpt from a controlled source, if located]
Source: [controlled file name / version]
Human review: Confirm test scope, actual compatibility envelope, and whether additional design analysis or testing is required.
```

The sample above is **hypothetical**, not a finding about a real product.

#### 6. AskDona Capability Boundaries and Positioning

<div class="table-scroll">

| Capability or claim | Status based on the provided AskDona material | Defensible customer-facing wording |
|---|---|---|
| Criteria/checklist ingestion using an Excel template | **Documented current capability** | Configure expert-authored misuse and control-effectiveness checks. |
| RAG-based document retrieval and source quotations | **Documented current capability** | Link preliminary conclusions to retrieved passages and source files. |
| Preliminary assessment labels, comments, evidence and references exported to Excel | **Documented current capability** | Prepare reviewable first-pass assessment reports. |
| Intake questions, metadata-based RAG scoping, applicability-based item skipping | **Documented current configuration features** | Scope review to selected devices, versions, and use contexts when correctly configured. |
| An explicit `Cannot determine` response | **Configurable label / documented practice** | Escalate missing evidence rather than forcing unsupported assurance. |
| Clinical/engineering determination of reasonably foreseeable misuse or risk-control sufficiency | **Not demonstrated as autonomous capability** | Experts define scope and make final safety decisions. |
| Automatic discovery of all possible misuse or accessory hazards | **Not established** | Use expert-curated scenarios; validate any AI-assisted scenario discovery separately. |
| Automatic effectiveness testing, risk probability calculation, or residual-risk acceptance | **Not established** | Review documented calculations and tests; do not replace engineering analysis. |
| Direct integration with QMS/PLM, continuous postmarket monitoring and automated change propagation | **Integration/roadmap concepts; implementation-specific** | Subject to interface design, qualification, permissions, and validation. |
| Byte-identical end-to-end reproducibility | **Demonstrated in a specific experimental research pipeline, not proven as a universal production guarantee** | Research supports feasibility under fixed conditions; validate the deployed workflow. |

</div>

**Research versus product distinction:** The supplied 2026-10-13 research draft tests reproducibility of document-assessment pipelines; it does **not** establish clinical correctness, adequacy of selected risk controls, regulatory approval, or generic time-saving performance for misuse assessment. The security-domain proof-of-concept results cited in the internal knowledge summary should likewise **not** be presented as verified performance for device safety reviews.

**Governance principle:** *AI prepares evidence-linked preliminary assessments; authorized subject-matter experts determine safety significance, assess the adequacy of controls, and make final regulatory/QMS decisions.* The original risk file and controlled QMS/PLM records remain authoritative.

#### 7. Expected Adoption Benefits and Pilot Measures

##### Expected benefits (prospective, not independently quantified for this use case)

1. **Reduced document-search burden:** More time for expert judgment and less time locating design, testing, labeling, and field evidence.
2. **More consistent assessment structure:** Reusable expert-defined criteria for foreseeable misuse, accessory interaction, control hierarchy, and effectiveness.
3. **Stronger decision traceability:** Explicit connections between misuse scenarios, hazardous situations, design-level safeguards, verification, and approved conclusions.
4. **Earlier visibility into warning-only rationales:** Clear identification of cases where product-specific evidence is missing or where the distinction between information-for-safety and engineering control has not been explained.
5. **Better cross-functional alignment:** Manufacturing, software, clinical, quality, and regulatory teams review a common evidence-backed first-pass record rather than disconnected conclusions.
6. **More effective review of new information:** Controlled reassessment when field data or configuration changes undermine earlier assumptions.

##### Suggested pilot

**Scope:** One product family, 2–3 relevant accessories or operating contexts, and approximately 20–40 selected use/misuse cases. Include examples where warning-based controls are appropriate, design controls are justified, and evidence remains incomplete.

**Preparation:** Qualified experts finalize assessment boundaries and 10–12 criteria; assemble approved versions of RMF/FMEA, design/architecture documents, interface data, V&V, labeling, HFE, complaints, ECOs, and CAPA as applicable.

**Execution:** Compare AskDona preliminary outputs against independent expert review; verify every quoted passage against its authoritative source. Keep a separate log of incorrect labels, irrelevant quotations, misleading absence-of-evidence conclusions, and scenario-scoping errors.

<div class="table-scroll">

| Evaluation metric | How to measure | Desired direction |
|---|---|---|
| Evidence retrieval precision | Share of quoted passages relevant and accurately copied | Increase |
| Risk-control linkage completeness | Scenarios with documented control → verification → residual-risk rationale | Increase |
| Unsupported “satisfied” rate | Unsubstantiated claims incorrectly treated as supported | Decrease |
| Uncertainty handling | Missing/conflicting cases correctly surfaced as `Cannot determine` | Improve |
| Scenario discrimination | Performance distinguishing accessory/version/environment differences | Improve |
| Specialist review effort | Minutes per case versus a manual baseline | Decrease, subject to validation |
| Review actionability | Share of flagged cases resolved with evidence or a documented expert disposition | Increase |
| Repeatability | Stability of labels **and quoted passages** on controlled identical-input reruns | Improve / validate |

</div>

**Pilot exit condition:** Proceed only when predefined thresholds for evidence faithfulness, unsupported assurance, reviewer workload, and software assurance are met; do not treat the AI output itself as an approved RMF conclusion.

#### 8. FDA URLs — Markdown Links for Reuse

The links below preserve the **supplied reference list**. The numbered references in Section 2 refer to these items; some links are FDA inspection guides rather than Warning Letters. **[Outdated — marked 2026-10-15]** Source titles, dates, and case-specific interpretations should be checked at the original URLs before external publication. **Updated (15 Oct 2026):** all 9 linked FDA pages were opened and each insight and finding checked; the result is given as a “Fact check” note. Titles, letter numbers and dates match. [2] and [8] are pages of FDA's 2014 EMC inspection guide and [9] is a 2014 food-industry guide for FDA investigators; none states a binding requirement on manufacturers.

1. [Happiest Baby, Inc. — Warning Letter 718306 (06/15/2026)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/happiest-baby-inc-718306-06152026)
2. [FDA — EMC MDQS, Page 5 (inspection guidance)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/inspection-guides/emc-mdqs-page-5)
3. [Onkos Surgical, Inc. — Warning Letter 712573 (07/21/2025)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/onkos-surgical-inc-712573-07212025)
4. [Unilam Co., LTD — Warning Letter 738562 (09/22/2026)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/unilam-co-ltd-738562-09222026)
5. [Centurion Medical Products Corporation — Warning Letter 598837 (06/11/2020)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/centurion-medical-products-corporation-598837-06112020)
6. [Beta Bionics, Inc. — Warning Letter 717927 (01/28/2026)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/beta-bionics-inc-717927-01282026)
7. [Sol-Millennium Medical, Inc. — Warning Letter 677524 (03/18/2024)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/sol-millennium-medical-inc-677524-03182024)
8. [FDA — EMC MDQS, Page 9 (inspection guidance)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/inspection-guides/emc-mdqs-page-9)
9. [FDA — Computerized Systems in the Food Processing Industry (inspection guidance)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/inspection-guides/computerized-systems-food-processing-industry-0)

---

**Positioning statement:** **AskDona Assessment helps product safety teams translate reasonably foreseeable misuse and risk-control questions into traceable, evidence-backed preliminary reviews.** It can expose unsupported reliance on labeling, incomplete accessory or environmental evaluations, and missing verification links while preserving qualified experts' responsibility for deciding what is reasonably foreseeable, what controls are effective, and what residual risk is acceptable.

---

## 16 Preventing plausible but unsupported AI-generated assessments

**Category: RISK | Subcategory: Operational**

Assessment area: AI-assisted Assessment

Generative AI can accelerate the drafting and organization of quality and regulatory materials, but its outputs may contain generic or technically implausible failure modes and rationales. Such content can appear complete without reflecting actual product behavior. Reliable assessments therefore require expert review, grounding in product-specific data, and checks that each conclusion follows from the available evidence.

Generative AI tools can accelerate the preparation of assessment drafts and suggest candidate failure modes, but fluent text is not equivalent to technically valid reasoning. A practitioner described AI-generated risk-analysis material containing plausible-sounding failure modes that were not credible for the actual device. If copied into a formal FMEA, these statements could distort prioritization and create unnecessary or misleading controls.

Conversely, apparent completeness may conceal missing hazards specific to the device architecture, use environment, or clinical workflow. Reviewers therefore need product-specific knowledge to challenge assumptions, verify the relevance of sources, and distinguish useful drafting assistance from unsupported conclusions. The assessment burden is not removed by AI; part of it shifts to checking the technical validity of the proposed content.

The main challenge is to use generative tools for bounded support tasks while retaining accountable expert review of the evidence, assumptions, failure mechanisms, and conclusions in regulated assessment records.

---

### AskDona Assessment — Preventing Plausible but Unsupported AI-Generated Assessments

**Topic:** 16 — Preventing plausible but unsupported AI-generated assessments  
**Category:** RISK | **Subcategory:** Operational  
**Assessment area:** AI-assisted Assessment  
**Assessment status:** Current · verified 2026-10-15 (challenge classification as supplied)  
**Document prepared:** 2026-10-16

> **Interpretation and claim boundaries.** The challenge in Section 1 is reproduced verbatim from the supplied text. The quotations in Section 2 and the findings below are **verbatim excerpts from the user-supplied analysis of FDA Warning Letters**, **not direct quotations from FDA Warning Letters**. They illustrate analogous deficiencies in human-prepared risk management; they do not establish that the cited manufacturers used generative AI. Source URLs are retained in Section 8 as copyable Markdown links. Product capabilities are differentiated as **documented existing**, **configurable workflow**, **research-demonstrated**, or **proposed / integration-dependent**. A preliminary AskDona finding is not a regulatory compliance determination.

#### 1. Original Challenge — Verbatim

##### 1.1 Summary

> Generative AI can accelerate the drafting and organization of quality and regulatory materials, but its outputs may contain generic or technically implausible failure modes and rationales. Such content can appear complete without reflecting actual product behavior. Reliable assessments therefore require expert review, grounding in product-specific data, and checks that each conclusion follows from the available evidence.

##### 1.2 Full original discussion

> Generative AI tools can accelerate the preparation of assessment drafts and suggest candidate failure modes, but fluent text is not equivalent to technically valid reasoning. A practitioner described AI-generated risk-analysis material containing plausible-sounding failure modes that were not credible for the actual device. If copied into a formal FMEA, these statements could distort prioritization and create unnecessary or misleading controls.
>
> Conversely, apparent completeness may conceal missing hazards specific to the device architecture, use environment, or clinical workflow. Reviewers therefore need product-specific knowledge to challenge assumptions, verify the relevance of sources, and distinguish useful drafting assistance from unsupported conclusions. The assessment burden is not removed by AI; part of it shifts to checking the technical validity of the proposed content.
>
> The main challenge is to use generative tools for bounded support tasks while retaining accountable expert review of the evidence, assumptions, failure mechanisms, and conclusions in regulated assessment records.

##### 1.3 Core assessment problem

The risk is **unearned credibility**: polished language may cause an unsupported FMEA entry to be accepted while product-specific hazards are missed. AskDona's appropriate role is to perform a **criteria-based, source-linked preliminary review** of a draft or existing assessment, expose missing or contradictory evidence, and hand the result to accountable specialists. It should neither invent credible failure mechanisms nor certify an FMEA as complete.

#### 2. FDA Warning Letter–Derived Insights — Verbatim Supplied Analytical Wording

The following are selected **original sentences from the accompanying FDA-derived analysis**, rather than direct FDA text. The source numbers refer to the clickable URL register in Section 8.

##### 2.1 Unsupported risk ratings and site assumptions

> An AI-generated FMEA might assign standard, template-based severity ratings without evaluating the actual manufacturing process or customer use case. This matches a failure by **Phillips Precision, Inc.**, which utilized a Process FMEA (PFMEA) to assess quality risk levels [11]. They assigned a severity score of 4 out of 5 for almost all failure modes for devices cleaned with their cleaning system *without* verifying if their firm was performing the "final clean" [11].

#**Fact check (16 Oct 2026, against the linked FDA letters):** **Partly supported; details corrected.** Phillips Precision [11] is a contract manufacturer of orthopedic implants and instruments that also performs the final cleaning for some customers. FDA found the PFMEA assigned a severity score “for all but one of the failure modes” for devices cleaned with its Zenith system “without determining if your firm was the final clean” (21 CFR 820.75(a)). “Almost all” should read all but one; the scale values are redacted, so “4 out of 5” cannot be confirmed (only “a severity score of 4” is visible); and the stated purpose of assessing quality risk levels comes from the firm's own SOP.

#### 2.2 Inconsistent severity for the same harm

> **Zimmer Biomet, Inc.** showed historical inconsistencies in the assignment of severity scores for identical failure effects [2]. In their PFMECA, the failure effect of "compromise of the product sterility" was given low severity ratings (necessitating minor intervention) in some line items and high severity ratings (permanent impairment or surgical intervention) in others [2].

#**Fact check (16 Oct 2026, against the linked FDA letters):** **Partly supported.** Zimmer Biomet [2] (shoulder implant): FDA confirmed “inconsistencies in the assignment of potential severity ratings” in PFMECA #PF0700, where the effect “Compromise of the product Sterility” was rated as necessitating minor medical intervention in some line items and as permanent impairment / surgical intervention in others. “Historical inconsistencies” is the **firm's own admission** as FDA reports it, “identical failure effects” is the analysis's wording, and the numeric ratings are redacted.

#### 2.3 Flawed calculation logic

> **Medtronic, Inc.** utilized a risk calculation formula that underestimated the probability of occurrence of harm, allowing them to classify a critical failure mode as "improbable" [15].

#**Fact check (16 Oct 2026, against the linked FDA letters):** **Partly supported.** Medtronic [15] (MiniMed 600 series insulin pumps): the firm's “risk calculation formula underestimated the probability of occurrence of harm.” “Improbable” was the **firm's own** rating of the risk of serious adverse health consequences from defective retainer rings, which FDA quotes in order to dispute; the letter does not use “critical failure mode”.

#### 2.4 Missing device-specific clinical hazards

> The firm completed a generic risk management review, but failed to assess risks specific to fetal monitoring, such as:
> *   The vulnerability of fetal tissue to prolonged ultrasound exposure [16].
> *   The risk of misinterpreting maternal heartbeats or placental blood flow as a fetal heartbeat, which could falsely reassure clinicians and lead to delayed care or fetal death [16].

#**Fact check (16 Oct 2026, against the linked FDA letters):** **Mostly supported.** Koven [16] (Bidop fetal Doppler): the risk report “fails to evaluate risks to the fetus”, including misinterpretation of maternal heartbeats or placental blood flow as fetal heartbeat, false reassurance, delayed care and fetal death. The letter says fetal tissue is more vulnerable to “prolonged or inappropriate” ultrasound exposure, and also lists thermal effects and acoustic exposure; “generic” is the analysis's characterization.

#### 2.5 Narrow DFMEA and weak controls

> **Unilam Co., Ltd.** had a Design FMEA (DFMEA) that only addressed 4 risk line items [5]. Their identified risk controls relied almost entirely on labeling or downstream actions by third-party manufacturers (such as using external timers or UV filters) rather than design-level controls within their own manufacturing process [5]. Furthermore, their DFMEA completely omitted the foreseeable risk of chemical exposure in the event of lamp breakage [5].

#**Fact check (16 Oct 2026, against the linked FDA letters):** **Partly supported.** Unilam [5]: the DFMEA “only addresses 4 risk line items”, controls “rely almost entirely on labeling” rather than design-level controls in the firm's own process, and lamp-breakage chemical exposure is not addressed. The downstream controls were “use of a timer or UV filter” by the single downstream sunlamp-bed manufacturer, not “external timers or UV filters” by “third-party manufacturers”.

#### 2.6 Missing actual hardware and software interactions

> **Beta Bionics, Inc.** failed to incorporate known system and clinical hazards into their System Risk Analysis for an insulin pump [7]. Their risk files failed to analyze:
> *   Clinical hypoglycemia risks resulting from involuntary meal announcements (a software-user interface interaction) [7].
> *   Physical printed circuit board assembly malfunctions from a specific hardware supplier [7].

#**Fact check (16 Oct 2026, against the linked FDA letters):** **Partly supported.** Beta Bionics [7] (iLet pump and dosing software): the risk analysis “fails to assess hypoglycemia risk from involuntary meal announcements” and does not assess or control hardware hazards from a supplier-manufactured printed circuit board assembly (61 mainboards failed testing). The document is the System Risk Analysis RA000005; “software-user interface interaction” is the analysis's label, not FDA's.

#### 2.7 Risk files disconnected from emerging postmarket experience

> **Meridian Bioscience, Inc.** failed to update their DFMEA, PFMEA, and UFMEA after becoming aware of an increase in false-positive complaints and separate labeling control failures [13]. Because the files remained un-updated, their risk profile failed to reflect the actual, ongoing product behavior [13].

#**Fact check (16 Oct 2026, against the linked FDA letters):** **Supported, with one precision.** Meridian Bioscience [13] (IVD devices): the DFMEA, PFMEA and UFMEA were not updated after the firm became aware of an increase in false-positive complaints. The two labeling-control failures (March 2023 and May 2024) are tied by FDA to the **PFMEA** only. The CAPA mentioned is a firm commitment.

#### 2.8 Biased selection of source evidence

> During a Health Hazard Evaluation (HHE) for degraded polyethylene implants, their complaint search criteria was restricted solely to "polyethylene wear" and "osteolysis," ignoring other critical harms documented in their own Risk Assessment and Controls Report, such as joint subluxation, migration, loss of range of motion, and dislocation [4].

#**Fact check (16 Oct 2026, against the linked FDA letters):** **Partly supported; search terms corrected.** Exactech [4] (Equinoxe shoulder polyethylene implants in out-of-specification vacuum bags): the HHE search named four terms (polyethylene wear, osteolysis, poly component fracture, disassociation), but the data analyzed covered only polyethylene wear (11 complaints). The harms (instability, subluxation, loss of range of motion, subsidence, migration, pain, dislocation) are from the firm's own Risk Assessment and Controls Report; FDA's finding is that such failure modes and complaint text were not included in the search scope. “Restricted solely to” two terms is incorrect.

#### 2.9 Unsupported implementation and verification claims

> **Lion Street Medical (dba Pensar Medical, LLC)** maintained a DFMEA for a software-controlled medical device where critical software, sterilization, packaging, and exudate management risk control verification entries were simply marked "In Progress" [12]. At the time of inspection, these risk controls had not actually been implemented or verified, leaving the device safety profile completely unproven [12].

**Fact check (16 Oct 2026, against the linked FDA letters):** **Supported, with small fixes.** Pensar Medical [12] (negative-pressure wound therapy systems): the risk-control verification entries for software, sterilization, storage, packaging and exudate management in the dFMEA were all marked “In Progress” and had not been implemented and verified at inspection. The list omits “storage”, and “software-controlled device” is not FDA's description.

#### 3. Findings, AskDona Perspective, Solutions, and Expected Benefits

##### Finding 01 — A credible-looking severity score may have no product-specific basis

**Original FDA-derived insight:** Section 2.1 ([Phillips Precision, #11](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/phillips-precision-inc-697119-12092024)).

**Regulatory finding / issue:** The risk rating is recorded without establishing the actual process role, downstream processing, device configuration, or customer-use assumptions.

**AskDona Assessment perspective:** Assess the *evidentiary basis for the rating*, not whether a language model can generate a plausible number. Require the assessor to identify the affected configuration, harm definition, relevant SOP scale, and underlying process evidence.

**AskDona solution:** Configure expert-authored Excel assessment criteria for severity-source identification; retrieve applicable SOPs, process maps, customer specifications, PFMEA and process-validation records from a scoped RAG repository; produce item-by-item **Satisfied / Gap / Cannot determine** preliminary results with reasons and citations. Escalate unsupported numbers to process and risk specialists.

**Expected benefit:** Fewer unexamined assumptions, faster evidence gathering, and more defensible severity justifications.

**Capability boundary:** Document retrieval, configurable criteria, first-pass findings and citation output are documented. Independent physical validity of severity estimates is **not** established.

##### Finding 02 — Identical failure effects can receive contradictory ratings

**Original FDA-derived insight:** Section 2.2 ([Zimmer Biomet, #2](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/zimmer-biomet-inc-558176-08242018)).

**Regulatory finding / issue:** Inconsistent rating conventions can hide the need for additional controls and undermine comparability across FMEA rows.

**AskDona Assessment perspective:** The evaluation should test whether shared severity definitions and comparable harm endpoints are justified consistently, while permitting explained differences in clinical circumstances.

**AskDona solution:** Import a standardized set of expert-defined consistency checks. Use source-linked preliminary reviews of FMEA entries and risk SOPs to flag discrepant severity descriptions and missing explanations. Have specialists adjudicate whether scenarios are actually comparable.

**Expected benefit:** More coherent cross-document risk narratives and clearer prioritization of review effort.

**Capability boundary:** Automated comprehensive semantic comparison of every FMEA row is a **proposed, test-dependent workflow**; do not imply that all contradictions will be found automatically.

##### Finding 03 — Fluent explanations can hide mathematically invalid classifications

**Original FDA-derived insight:** Section 2.3 ([Medtronic, #15](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/medtronic-inc-617539-12092021)).

**Regulatory finding / issue:** An incorrect formula or probability definition can make an incorrect risk category appear properly justified.

**AskDona Assessment perspective:** Separate narrative/evidence checks from deterministic numerical validation. The appropriate risk method depends on the controlled SOP and device context; a generic multiplication formula is not universally sufficient.

**AskDona solution:** Check whether calculations, approved risk scales, assumptions and supporting evidence are documented. For numerical correctness, pair AskDona's preliminary evidence review with **independently validated spreadsheet or rules-based calculation controls**, followed by qualified reviewer confirmation.

**Expected benefit:** Better visibility into unsupported ratings and lower likelihood that prose conceals calculation errors.

**Capability boundary:** A validated formula engine, automatic numerical audit or clinical risk acceptance determination is **not a confirmed built-in AskDona capability**.

##### Finding 04 — Generic hazard lists omit clinically specific mechanisms

**Original FDA-derived insight:** Section 2.4 ([Koven Technologies, #16](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/koven-technologies-inc-734643-07212026)).

**Regulatory finding / issue:** A polished list of general hazards may omit device-specific use conditions, physiological interactions and potentially severe harms.

**AskDona Assessment perspective:** A critical review should ask whether *expert-identified, product-specific scenarios* are represented and supported. Absence of a source passage cannot prove that every relevant hazard has been identified.

**AskDona solution:** Have clinical and design specialists define coverage criteria for intended users, environments, use tasks, physical mechanisms and patient consequences. Check the existing risk file against device specifications, clinical-use descriptions, complaints and test reports; report missing traceability and uncertain coverage.

**Expected benefit:** Earlier detection of known but undocumented clinical scenarios and reduced false confidence in generic drafts.

**Capability boundary:** Exhaustive hazard discovery or expert-grade clinical reasoning by the AI is **not established**.

##### Finding 05 — Suggested controls may be generic rather than demonstrated safeguards

**Original FDA-derived insight:** Section 2.5 ([Unilam, #5](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/unilam-co-ltd-738562-09222026)).

**Regulatory finding / issue:** An FMEA can list warnings and third-party actions while omitting product-specific hazardous situations or the manufacturer's design-control evidence.

**AskDona Assessment perspective:** Treat existence, implementation and verified effectiveness of a risk control as distinct criteria; do not infer effectiveness from the presence of a control description.

**AskDona solution:** Compare DFMEA control claims with architecture, design changes, design verification, labeling, validation reports and approved risk assessments. Generate first-pass evidence gaps for each control ID and request human review where design-level mitigation is absent or unclear.

**Expected benefit:** Stronger links between claimed mitigation and actual implementation/verification; less reliance on generic wording.

**Capability boundary:** AskDona does not establish whether a design control is physically sufficient or reduce residual risk to an acceptable level on its own.

##### Finding 06 — AI-assisted risk files can overlook supplier- and interface-specific hazards

**Original FDA-derived insight:** Section 2.6 ([Beta Bionics, #7](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/beta-bionics-inc-717927-01282026)).

**Regulatory finding / issue:** Clinical software behavior and supplier-dependent hardware failures can be omitted despite being relevant to the device.

**AskDona Assessment perspective:** Examine both *coverage of known product-specific events* and whether each event is considered in the right assessment context (system, design, software, usability or supplier risk).

**AskDona solution:** Scope evidence by product, software version, supplier and subsystem using metadata filters and pre-assessment questions; cross-check expert-specified risk entries against software requirements, supplier NCRs, complaint investigations and design records.

**Expected benefit:** More focused retrieval and fewer overlooked links between field failures and existing risk analyses.

**Capability boundary:** Configured metadata filtering is documented; automated supplier/QMS synchronization and complete cross-system hazard discovery require integration and validation.

##### Finding 07 — A static AI-generated FMEA can become obsolete

**Original FDA-derived insight:** Section 2.7 ([Meridian Bioscience, #13](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/meridian-bioscience-inc-720826-12222025)).

**Regulatory finding / issue:** New complaints or labeling problems may invalidate assumptions in an earlier risk analysis.

**AskDona Assessment perspective:** An assessment should be explicitly time-bound: document version, evidence cutoff and relevant postmarket reporting period need to be recorded.

**AskDona solution:** Re-run configured checks with an updated, curated evidence repository and compare expert-reviewed findings over defined review cycles. Include criteria for whether new complaint themes were evaluated and whether responsible teams approved resulting dispositions.

**Expected benefit:** Better reassessment discipline and clearer visibility of outdated assumptions.

**Capability boundary:** Re-running current assessment workflows is supported; continuous automatic monitoring, reliable differential re-assessment and live QMS connections are **not assumed to be generally available**.

##### Finding 08 — A search can look evidence-based while missing essential clinical synonyms

**Original FDA-derived insight:** Section 2.8 ([Exactech, #4](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/exactech-inc-669904-01192024)).

**Regulatory finding / issue:** Narrow complaint search terms may suppress relevant symptoms or failure manifestations, leading to misleading assessment conclusions.

**AskDona Assessment perspective:** Retrieval quality and **evidence coverage** must be validated independently of the eloquence of the final comment. A citation is not proof that all relevant evidence was found.

**AskDona solution:** Let experts define concept families, alternative clinical descriptions and exclusion rules; review retrieval results against an adjudicated benchmark of known relevant complaints; use **Cannot determine** where evidence coverage is inadequate.

**Expected benefit:** More reviewable search assumptions and a reduced chance of accepting a selectively supported narrative.

**Capability boundary:** RAG search and cited evidence output are existing functions. Guaranteed exhaustive retrieval, ontology-driven expansion and measured recall are **not built-in guarantees**.

##### Finding 09 — Documented controls may exist only on paper

**Original FDA-derived insight:** Section 2.9 ([Lion Street Medical, #12](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/lion-street-medical-dba-pensar-medical-llc-733015-08212026)).

**Regulatory finding / issue:** A proposed mitigation or an “In Progress” verification field is not proof of implemented and effective control.

**AskDona Assessment perspective:** Validate the **status and evidence state** of each mitigation claim, and distinguish planned, implemented, verified and approved records.

**AskDona solution:** Configure criteria requiring implementation record ID, linked verification protocol/report, outcome, deviations and responsible approval. Review the evidence across available risk, design and test records and flag missing or incomplete status evidence.

**Expected benefit:** Clearer closure criteria and fewer unsupported “control complete” assertions entering final regulated records.

**Capability boundary:** Initial document review and citations are supported. AskDona does not independently perform tests, authorize closure or create compliant approval signatures.

#### 4. Proposed Assessment Operating Model

1. **Set boundaries and accountability.** QA/RA and product experts determine the intended use of AI, applicable procedures, review authority and accepted label definitions.
2. **Define expert-authored criteria.** Convert recurring quality questions into measurable checks: device-specific relevance, risk score justification, traceability, evidence existence, source validity, control status and postmarket alignment.
3. **Prepare a controlled evidence repository.** Load the applicable RMF, FMEA, requirements, design records, validation, supplier and complaint records. Capture file version and product-context metadata, avoid stale duplicates, and control access.
4. **Run AskDona's first-pass assessment.** Import criteria from Excel, filter by product/context, and generate a preliminary **label, comment, quoted evidence and source file** for each item.
5. **Apply deterministic checks outside the language model where appropriate.** Independently validate formulas, lookup tables, numeric bounds and any hard acceptance rule through controlled spreadsheet/software procedures.
6. **Review by qualified experts.** Inspect original documents and quotations; decide whether failure mechanisms are technically plausible, clinically consequential and properly categorized; challenge omissions and unsupported claims.
7. **Record final disposition in the controlled QMS/RMF.** Preserve the reviewer decision, rationale, corrected records, control owner and approval. The AI result is supporting material, not the final quality decision.
8. **Reassess at defined triggers.** Re-run on updated datasets after complaints, supplier problems, design changes and regulatory procedure changes; record which evidence and criteria were used.

#### 5. Example Criteria for an AskDona Pilot

These are **proposed customer-configured criteria**, not an assertion that AskDona ships with a ready-made FDA-approved FMEA checklist.

<div class="table-scroll">

| ID | Expert-authored assessment criterion | Expected evidence | Escalation trigger |
|---|---|---|---|
| AI-01 | Every sampled proposed failure mode is linked to a real device function, component, process or use task. | Architecture, BOM, specifications, process flow, FMEA | Generic or unlocatable failure mechanism |
| AI-02 | Technical plausibility is reviewed by a qualified product specialist. | Design review/approval notes | No reviewer or unsupported assumptions |
| AI-03 | Severity descriptions and source-specific SOP scale are documented. | Risk SOP, clinical rationale, FMEA | Unjustified score or scale mismatch |
| AI-04 | Any quantitative probability estimate identifies its underlying data and method. | Complaints, field exposure, reliability data, SOP | AI-invented numeric value |
| AI-05 | Numerical classification has been independently checked using an approved method. | Controlled calculation worksheet or validated rules | Missing independent calculation check |
| AI-06 | Device-specific clinical and use-environment hazards identified by experts appear in the relevant risk record or have documented disposition. | URRA, RMF, clinical review, use scenarios | Unexplained absence or incomplete coverage |
| AI-07 | Each claimed risk control is tied to the actual controlled implementation record. | Change/design records, specifications | Only a textual suggestion exists |
| AI-08 | Each implemented control has appropriate verification/validation evidence and an explicit outcome. | Test protocols, reports, deviation records | Verification missing or “In Progress” |
| AI-09 | Current complaint and supplier data were considered within a stated reporting period. | PMS, NCR, CAPA, supplier records | Evidence cutoff unclear or outdated |
| AI-10 | Search concepts include clinically related manifestations when applicable. | Query protocol, complaint taxonomy, reviewed search result | Overly narrow search terms |
| AI-11 | AI-generated assertions have verifiable, relevant source quotations. | Assessment output and original controlled files | Unsupported, mismatched or unverifiable passage |
| AI-12 | A responsible expert recorded the final assessment disposition. | Approved QMS/RMF record | Preliminary AI output mistaken for approval |

</div>

**Illustrative preliminary output (hypothetical, not an actual product run):**

```text
Criterion: AI-08
Preliminary result: Cannot determine
Comment: A mitigation is listed in the current DFMEA, but the supplied records
         do not identify a completed verification report for this control.
Evidence: [exact retrieved quotation, if available]
Source file: [controlled document ID, version]
Reviewer action: Confirm implementation and verification status in the QMS;
                 determine whether the risk record requires correction.
```

**Interpretation rule:** A missing citation means **not established from the indexed evidence**, not automatically “the organization is noncompliant” or “the hazard does not exist.”

#### 6. AskDona Capability Status and Non-Claims

<div class="table-scroll">

| Function or proposition | Status supported by the supplied materials | How to present it accurately |
|---|---|---|
| Excel-based import of predefined assessment criteria | **Documented existing** | Run a standardized quality/risk checklist authored by specialists. |
| RAG retrieval from an assessment-linked document repository | **Documented existing** | Find relevant document passages for each assessment question. |
| Item-level label, explanatory comment, direct quotation, file reference, Excel export | **Documented existing** | Produce evidence-linked first-pass findings for reviewer confirmation. |
| Pre-assessment questions, metadata scoping, inapplicability filtering | **Documented existing / configurable** | Limit review to defined product and document context when configured correctly. |
| “Cannot determine” for insufficient evidence | **Configurable existing approach** | Escalate uncertainty instead of inventing a definitive judgment. |
| Final determination of failure-mode realism, clinical harm, risk acceptability or FMEA completeness | **Expert responsibility** | Do not advertise autonomous risk approval or exhaustive hazard identification. |
| Automatic validation of numeric formulas, full cross-row consistency and exhaustive complaint recall | **Not confirmed as native capabilities** | Add independently controlled checks and measure performance in a pilot. |
| Real-time multi-system QMS/PLM/CAPA integration or continuous change detection | **Integration-dependent / proposed** | Design and validate separately; do not imply an active production connection. |
| End-to-end byte-identical assessment pipeline | **Research-demonstrated under specified test conditions** | A research result, not a claim that every current commercial configuration is deterministic. |

</div>

**Important reproducibility distinction.** The supplied research draft compared 13 commercial LLM deployments: 11 showed at least some label variation on repeated tests. A specifically configured research pipeline reproduced all intermediate outputs in the reported medical-device experiments. That result establishes feasibility under those conditions, **not assessment correctness or general production deployment parity**. Quotation/source validation and expert assessment of whether evidence truly supports a conclusion remain necessary.

#### 7. Pilot, Measures and Expected Organizational Benefits

##### 7.1 Recommended pilot

Select **one device family**, approximately **25–40 sampled risk/FMEA lines**, and a deliberately mixed set of cases: technically credible failure modes, implausible AI-suggested mechanisms, missing clinical hazards, ambiguous scoring, outdated occurrence estimates and unverified controls. Include versioned design, test, complaint and supplier records. Experts define a reference judgment independently before evaluating AskDona outputs.

##### 7.2 KPI framework — to be measured, not promised

<div class="table-scroll">

| KPI | Pilot measurement | Intended benefit |
|---|---|---|
| Grounding precision | Share of cited excerpts that truly support the specific claim | Fewer persuasive but unsupported statements |
| Unsupported-assertion detection | Recall/precision for expert-labeled unsupported risk statements | Better first-pass screening |
| Missing-hazard coverage | Proportion of expert-seeded omissions correctly escalated | Lower false completeness |
| Appropriate abstention | Rate of “Cannot determine” on deliberate missing-evidence cases | Less false assurance |
| Cross-source consistency | Number of materially inconsistent ratings identified per review | More comparable risk rationale |
| Evidence assembly effort | Expert time spent locating and recording sources | Faster document-heavy review |
| Control verification coverage | Proportion of claimed controls with located implementation/test evidence | More reliable control closure |
| Expert disposition completeness | Share of findings with documented reviewer decision and rationale | Better QMS traceability |
| Re-review stability | Label, comment, file and passage differences on repeated fixed-input runs | Better understanding of reproducibility |

</div>

##### 7.3 Expected benefits

A successfully validated deployment could reduce manual source-search effort, standardize scrutiny of AI-generated FMEA content, make unsupported assumptions visible, distinguish missing evidence from established deficiencies, and focus qualified personnel on the highest-value technical questions. The greatest value is **better-supported human judgment**, not the replacement of judgment. The supplied security-domain proof of concept reported over 91% accuracy and 45% effort reduction in that **specific context only**; these results are **not evidence of equivalent performance for medical-device risk assessment**.

#### 8. FDA Source Links — Copyable Markdown

These URLs are retained from the supplied FDA-derived analysis. **[Outdated — marked 2026-10-16]** **They have not been individually reverified in this deliverable**; confirm the specific allegation against the official FDA document before public release. **Updated (16 Oct 2026):** all 16 linked letters were opened; firm names, letter numbers and dates match, and each Section 2 insight carries a “Fact check” note. FDA inspection guides are not Warning Letters, and the cited cases do not independently demonstrate misuse of generative AI.

1. [Onkos Surgical, Inc. — 712573 — 07/21/2025](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/onkos-surgical-inc-712573-07212025)
2. [Zimmer Biomet, Inc. — 558176 — 08/24/2018](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/zimmer-biomet-inc-558176-08242018)
3. [Turkuaz Sağlik Hizmetleri — 649158 — 12/29/2022](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/turkuaz-saglik-hizmetleri-medikal-temizlik-kimyasa-649158-12292022)
4. [Exactech, Inc. — 669904 — 01/19/2024](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/exactech-inc-669904-01192024)
5. [Unilam Co., LTD — 738562 — 09/22/2026](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/unilam-co-ltd-738562-09222026)
6. [Bioptimal International — 678281 — 04/03/2024](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/bioptimal-international-678281-04032024)
7. [Beta Bionics, Inc. — 717927 — 01/28/2026](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/beta-bionics-inc-717927-01282026)
8. [Exactech, Inc. dba Advita Ortho — 720250 — 12/19/2025](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/exactech-inc-dba-advita-ortho-720250-12192025)
9. [Wissner-Bosserhoff GmbH — 690242 — 08/30/2024](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/wissner-bosserhoff-gmbh-690242-08302024)
10. [Beckman Coulter Inc. — 678042 — 03/15/2024](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/beckman-coulter-inc-678042-03152024)
11. [Phillips Precision, Inc. — 697119 — 12/09/2024](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/phillips-precision-inc-697119-12092024)
12. [Lion Street Medical, d/b/a Pensar Medical LLC — 733015 — 08/21/2026](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/lion-street-medical-dba-pensar-medical-llc-733015-08212026)
13. [Meridian Bioscience, Inc. — 720826 — 12/22/2025](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/meridian-bioscience-inc-720826-12222025)
14. [Xoran Technologies, LLC — 694229 — 12/09/2024](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/xoran-technologies-llc-694229-12092024)
15. [Medtronic, Inc. — 617539 — 12/09/2021](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/medtronic-inc-617539-12092021)
16. [Koven Technologies, Inc. — 734643 — 07/21/2026](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/koven-technologies-inc-734643-07212026)

**Fact check (16 Oct 2026, against the linked FDA letters):** None of the 16 letters mentions artificial intelligence, so the caveat above stands: the cases illustrate analogous human-prepared deficiencies. [1], [3], [6], [8], [9], [10] and [14] are listed but not cited in the text; [9] Wissner-Bosserhoff (nursing-bed handset resetting after power loss) contains no risk-analysis citation and is a weak fit for this list.

---

**Positioning statement:** *AskDona Assessment turns expert-authored risk-review criteria into source-linked preliminary checks of AI-assisted or human-authored assessments. It helps reviewers identify missing evidence, unsupported scores, inconsistent control claims and gaps between risk files and real product records—while the technical validity of failure mechanisms, completeness of hazard analysis, and final regulated judgment remain with qualified professionals.*

---

## 17 Identifying critical use tasks across overlapping methods

**Category: RISK | Subcategory: Product Safety**

Assessment area: Human Factors Assessment

Human factors assessments can be difficult when use-related risk analysis and conventional failure mode analysis overlap. Teams must distinguish the effects of user interaction from technical component failure, identify tasks whose incorrect performance could result in harm, and link those tasks to usability risk controls and validation evidence. Misalignment across assessment methods can cause critical use scenarios to be overlooked.

Human factors assessment requires a structured connection between user interactions, potential use errors, hazardous situations, and clinical consequences. Teams may encounter uncertainty when a Failure Mode and Effects Analysis and a Use-Related Risk Analysis appear to cover similar scenarios, but use different perspectives and documentation conventions. The apparent duplication makes it difficult to know where critical tasks should be identified and justified.

An assessment focused only on component or functional failures may not fully describe how a user misunderstands information, omits a step, or responds incorrectly under realistic conditions. Conversely, a usability exercise that is disconnected from the risk file may fail to show which tasks merit greater attention and what controls are being verified. Cross-functional input is needed to interpret the interaction between task performance, interfaces, and possible harm.

The central challenge is to define critical use tasks through a clear harm-based rationale and keep use-related analyses, risk controls, and usability validation evidence aligned without duplicating inconsistent conclusions across documents.

---

### AskDona Assessment — Identifying Critical Use Tasks Across Overlapping Methods

**Topic:** RISK 17 — Identifying critical use tasks across overlapping methods  
**Category:** RISK | **Subcategory:** Product Safety  
**Assessment area:** Human Factors Assessment  
**Prepared:** 2026-10-16  
**Focus:** URRA/FMEA alignment, clinical harm-based critical task identification, usability risk controls, human factors validation, and expert-approved traceability.

> **Interpretation and source integrity.** Section 1 reproduces the user-supplied challenge verbatim. The quoted FDA-derived insights in Section 2 and in the findings below reproduce wording from the **supplied analytical summary**; they are **not verbatim quotations from FDA Warning Letters**. Links to the related public FDA documents are retained at the end for copying and checking. Inspection guides are distinguished from Warning Letters. Individual FDA cases do not establish universal requirements for every device. All AskDona use cases below are proposed applications of documented capabilities, not claims of autonomous clinical judgment or regulatory compliance.

#### 1. Original Challenge — Verbatim

##### 1.1 Title and metadata

> 17 Identifying critical use tasks across overlapping methods Category: RISK | Subcategory: Product Safety  
> Assessment area: Human Factors Assessment

##### 1.2 Full original challenge

> Human factors assessments can be difficult when use-related risk analysis and conventional failure mode analysis overlap. Teams must distinguish the effects of user interaction from technical component failure, identify tasks whose incorrect performance could result in harm, and link those tasks to usability risk controls and validation evidence. Misalignment across assessment methods can cause critical use scenarios to be overlooked.
>
> Human factors assessment requires a structured connection between user interactions, potential use errors, hazardous situations, and clinical consequences. Teams may encounter uncertainty when a Failure Mode and Effects Analysis and a Use-Related Risk Analysis appear to cover similar scenarios, but use different perspectives and documentation conventions. The apparent duplication makes it difficult to know where critical tasks should be identified and justified.
>
> An assessment focused only on component or functional failures may not fully describe how a user misunderstands information, omits a step, or responds incorrectly under realistic conditions. Conversely, a usability exercise that is disconnected from the risk file may fail to show which tasks merit greater attention and what controls are being verified. Cross-functional input is needed to interpret the interaction between task performance, interfaces, and possible harm.
>
> The central challenge is to define critical use tasks through a clear harm-based rationale and keep use-related analyses, risk controls, and usability validation evidence aligned without duplicating inconsistent conclusions across documents.

##### 1.3 Core issue

The problem is **not** that URRA and FMEA must contain identical entries. They may legitimately use different units of analysis. The problem is that the organization must be able to explain how a user task, foreseeable use error, hazardous situation, possible harm, risk-control measure, and validation evidence relate to one another, especially where technical and use-related mechanisms interact. Identifying a critical task and establishing the acceptability of its residual risk remain expert responsibilities.

#### 2. FDA Warning Letter–Derived Insights — Verbatim Wording From the Supplied Analysis

These extracts are **original passages from the supplied FDA-derived analysis**, not direct FDA quotations. Bracketed numbers refer to the full clickable FDA URL list in Section 8.

##### 2.1 Technical failure versus use-related failure

> A common pitfall in product safety assessment is the failure to separate system design deficiencies from user training or interaction errors. This often results in corrective actions that focus solely on training improvements without addressing underlying device design flaws [6].

> Manufacturers must recognize that quality and functionality complaints cannot be automatically or exclusively attributed to application user failures [7]. If a device's user interface, alert systems, or mechanical tolerances contribute to maladaptive behaviors, the root cause is a system design issue rather than a user training deficiency [6].

##### 2.2 Defining critical tasks through clinical consequences

> Critical use tasks must be identified and prioritized based on a clear, clinical harm-based rationale [19, 20]. Focusing risk assessments too narrowly can lead to underestimating risks and down-classifying the severity of potential hazards [10, 13, 19].

> A robust clinical rationale maps a specific user interaction or use error directly to its worst-case clinical consequences [20, 22].

#**Fact check (16 Oct 2026, against the linked FDA pages):** **First sentence not supported; second partly supported.** Neither Medtronic [19] nor Koven [20] mentions critical use tasks or their prioritization. On narrow assessments: Beckman Coulter [10] (DxI 9000 immunoassay) found false-negative results “under classified” and severity incorrectly assessed; Medtronic [19] (MiniMed 600 pumps) and iRhythm [13] concern **underestimated probability** (a mortality-only risk calculation; a miscalculated health hazard evaluation), not severity. None of the three concerns use-related risk. The second paragraph is checked under Finding 02.

#### 2.3 Risk-file and validation traceability

> To ensure that identified critical tasks are validated, manufacturers must build a seamless bridge between the risk files, user requirements, and human factors validation evidence [2, 8, 9].

> Traceability must be established between product requirements and risks [2].

##### 2.4 Controls beyond labeling

> Relying heavily on labeling, instructions for use (IFU), or downstream user precautions is generally inadequate to mitigate critical use risks [1, 4].

##### 2.5 Human factors validation evidence

> Any design change intended to mitigate a usability risk (such as reducing plunger pullout or syringe cracking) must undergo user validation to confirm the changes do not adversely affect product use [7].

##### 2.6 Inconsistent risk scales and methodological conventions

> Methodological differences between engineering and usability teams often create inconsistent conclusions across risk documents [5, 13].

> Organizations must ensure that the impact and probability scales used to calculate risk are identical across various risk files [5].

#**Fact check (16 Oct 2026, against the linked FDA pages):** **Second sentence not supported as worded.** NeuroSync [5] does not require identical impact and probability scales across risk files: it found the scales “not adequately defined” in the firm's SOP and a software risk file that did not use RPNs as the procedure requires. The first sentence is checked under Finding 07.

#### 2.7 Postmarket feedback into both analyses

> Risk files (including DFMEAs and URRAs) must be treated as living documents and updated periodically based on customer complaints, competitor recalls, and clinical literature [2, 6, 17].

**Qualification:** The supplied analysis sometimes uses broad language about identical scales, user-validation sample sizes, and control hierarchy. These should be interpreted in the context of the device's applicable requirements and approved procedures; for example, a particular firm's 15-user procedural criterion is **not** a universal rule for every human factors study.

**Fact check (16 Oct 2026, against the linked FDA pages):** The 15-user criterion is in Zyno Medical [8]: the firm's own Usability Engineering SOP required 15 users for human-factors simulation testing, and FDA cited the firm because its study listed only 10.

#### 3. Detailed Findings and AskDona Assessment Mapping

Each finding includes **(A) FDA-derived original insight, (B) finding, (C) AskDona Assessment perspective, (D) proposed solution, (E) expected benefit, and (F) capability boundary**.

##### Finding 01 — User-error explanations obscure system design contributors

**A. FDA-derived original insight — verbatim**

> Manufacturers must recognize that quality and functionality complaints cannot be automatically or exclusively attributed to application user failures [7]. If a device's user interface, alert systems, or mechanical tolerances contribute to maladaptive behaviors, the root cause is a system design issue rather than a user training deficiency [6].

**B. Finding / observation:** A complaint characterized as operator error may also implicate interface interpretation, alarm presentation, device mechanics, or software behavior. A DFMEA entry and a URRA entry may describe different aspects of the same incident without clearly identifying their relationship.

**C. AskDona Assessment perspective:** Assess whether the documented causal analysis has considered *both* technical and use-related contributors; do not infer that an incident was caused by the user solely from the category assigned in one record.

**D. Proposed AskDona solution:** Import expert-defined criteria that check for (i) user step and observed behavior, (ii) interface and design contribution, (iii) corresponding DFMEA/URRA or investigation IDs, and (iv) disposition and evidence. Search controlled investigation reports, complaints, design specifications, risk files, and usability reports in a scoped RAG repository. Produce a first-pass label, explanation, verbatim source quotation, and source-file reference for qualified review.

**E. Expected benefit:** More consistent root-cause review, fewer unsupported user-error attributions, and clearer handoffs between human factors and engineering teams.

**F. Capability boundary:** Evidence retrieval and criteria-based preliminary assessment are documented. Root-cause determination and complete automated FMEA/URRA relationship discovery are **not established as autonomous capabilities**.

**Fact check (16 Oct 2026, against the linked FDA pages):** **Partly supported; wording corrected.** Medline [7]: FDA wrote that “all complaints cannot be attributed to application user failures” described in the firm's application FMEA; “automatically or exclusively” and “quality and functionality complaints” are the analysis's wording. Beta Bionics [6]: FDA found the corrective action “solely focused on training improvements without addressing potential device design issues”, and said it was not clear whether the user interface, alert systems or other design issues could have contributed to “maladaptive behaviors”. That is raised as an open question, not a finding that the root cause is system design, and “mechanical tolerances” does not appear in the letter.

##### Finding 02 — Critical tasks are not justified by a clear harm pathway

**A. FDA-derived original insight — verbatim**

> A robust clinical rationale maps a specific user interaction or use error directly to its worst-case clinical consequences [20, 22].

**B. Finding / observation:** A task list may be labeled “critical” without explaining the use error, foreseeable hazardous situation, or potential clinical harm. Conversely, clinically consequential tasks may be absent from the list.

**C. AskDona Assessment perspective:** Treat **task → use error → hazardous situation → harm → critical-task disposition** as an expert-authored evidence chain to be checked, not a harm judgment to be invented by the system.

**D. Proposed AskDona solution:** Evaluate every selected task against criteria requiring the use scenario, task step, possible incorrect action/omission/misinterpretation, causal pathway, potential harm, and documented criticality rationale. Compare task analyses and URRAs with clinical-risk justifications and approved task inventories. Mark insufficiently supported claims **Cannot determine** rather than fabricating a harm pathway.

**E. Expected benefit:** Better visibility into unexplained task classifications and potentially overlooked use scenarios; stronger rationale for selecting tasks for validation.

**F. Capability boundary:** AskDona can review **predefined** criteria and supplied evidence; exhaustive discovery of all clinically critical tasks requires expert hazard analysis and is not guaranteed.

**Fact check (16 Oct 2026, against the linked FDA pages):** **Partly supported.** Koven [20] (Bidop Doppler): FDA found the risk files fail to evaluate risks to the fetus after the indications were expanded, explaining that improper use may cause maternal heartbeats to be misinterpreted as fetal heartbeats, with missed distress signals, delayed care and possible fetal death. WHOOP [22] is an unapproved-device letter: an erroneously low or high blood-pressure reading can delay treatment, which is a measurement-accuracy point rather than a use error. Neither letter uses “use error” or “critical task”.

##### Finding 03 — Apparent URRA–DFMEA duplication causes mismatched or missing coverage

**A. FDA-derived original insight — verbatim**

> When use-related risk analysis (URRA) and conventional failure mode and effects analysis (FMEA) overlap, medical device manufacturers often struggle to maintain alignment. Misalignment across these methods can cause critical use scenarios to be overlooked, or lead to inconsistent risk ratings across documents [6, 7].

**B. Finding / observation:** Teams may either duplicate the same narrative with divergent risk classifications or omit the human–device interaction because a technical failure is already listed.

**C. AskDona Assessment perspective:** Review **coverage and cross-references**, not forced row-for-row uniformity. One technical failure can lead to several use scenarios; one use error can interact with multiple technical contributors.

**D. Proposed AskDona solution:** Use an expert-maintained crosswalk of task IDs, URRA risk IDs, DFMEA IDs, interface requirements, and hazard IDs. Configure criteria for missing relationships, inconsistent descriptions and unsupported “covered elsewhere” assertions. Return source-linked first-pass gaps for reconciliation by both groups.

**E. Expected benefit:** Lower risk of silent scenario omission and less duplicated, contradictory narrative in controlled records.

**F. Capability boundary:** The platform can evaluate supplied crosswalk/checklist evidence. An automatically built and continuously synchronized graph across PLM/QMS tools is an **integration/roadmap concept**, not an established standard feature.

**Fact check (16 Oct 2026, against the linked FDA pages):** **Not supported.** No cited letter discusses overlap or misalignment between a use-related risk analysis and an FMEA, and the acronym “URRA” appears in none of the 15 sources. Beta Bionics [6] mentions a firm document titled “User-Related Risk Analysis” but no FMEA; Medline [7] notes that neither the DFMEA nor the application FMEA was updated. This finding is the analysis's own framing.

##### Finding 04 — Risk controls lack traceable verification or usability validation

**A. FDA-derived original insight — verbatim**

> To ensure that identified critical tasks are validated, manufacturers must build a seamless bridge between the risk files, user requirements, and human factors validation evidence [2, 8, 9].

**B. Finding / observation:** A risk control may be named in a URRA, but its implementation, test reference, simulated-use outcome, or unresolved participant difficulty may be missing.

**C. AskDona Assessment perspective:** Check the evidentiary completeness of **critical task → associated use-related risk → risk control → implementation/verification → human factors validation result**.

**D. Proposed AskDona solution:** Assess selected task/control pairs against design-control and usability evidence. Search UI specifications, IFUs, test protocols, participant observations, deviations, usability validation reports, and risk-control verification documents. Output missing links and cited excerpts in the assessment spreadsheet.

**E. Expected benefit:** Faster preparation for design reviews and regulatory submissions; review teams can focus on unsupported control-effectiveness assertions.

**F. Capability boundary:** Presence/consistency checks are feasible. AskDona does **not** itself perform user testing or scientifically establish that a control is effective.

**Fact check (16 Oct 2026, against the linked FDA pages):** **Partly supported; the “bridge” is the analysis's synthesis.** Philips [2]: new product requirements were not included in the ISCV risk management matrix; traceability between requirements and risks was the **firm's own corrective commitment**, not an FDA requirement, and the letter has no human-factors content. Zyno Medical [8] (Z-800 infusion pumps): user needs were not adequately validated and the human-factors simulation study used 10 users rather than the 15 required by the **firm's own SOP**; the letter does not discuss risk files. Anigan [9] (menstrual cups): the firm had no risk analysis in design and no design validation; human factors appears only as an FDA guidance title.

##### Finding 05 — Labeling or training is accepted without assessing safer design options

**A. FDA-derived original insight — verbatim**

> Relying heavily on labeling, instructions for use (IFU), or downstream user precautions is generally inadequate to mitigate critical use risks [1, 4].

**B. Finding / observation:** Instructions or user training may be the sole documented mitigation even when a foreseeable misinterpretation or use error raises a design question.

**C. AskDona Assessment perspective:** Ask whether the record shows an actual control-selection rationale, and whether verification and usability validation address the relevant task and harm scenario.

**D. Proposed AskDona solution:** Configure criteria requiring a documented review of possible design, protective and information-for-safety measures under the organization's applicable risk-control procedure. Compare the risk-control decision with interface designs, IFU revisions, testing, and validation results. Escalate absent or contradictory rationales to expert reviewers.

**E. Expected benefit:** Better-informed cross-functional evaluation of controls and reduced reliance on unsupported “training will solve it” statements.

**F. Capability boundary:** AskDona can identify missing documented rationale; it cannot select an engineering safeguard, prescribe a universal hierarchy for every context, or approve residual risk.

**Fact check (16 Oct 2026, against the linked FDA pages):** **Supported.** EMC inspection guide [1]: “labeling in place of design controls usually is not adequate to prevent adverse events”, in the context of electromagnetic interference only. Unilam [4] (UV sunlamp): risk controls “rely almost entirely on labeling” and on actions outside the manufacturer's control. Neither source concerns use-related or human-factors risk specifically.

##### Finding 06 — Validation coverage does not substantiate critical-task conclusions

**A. FDA-derived original insight — verbatim**

> Any design change intended to mitigate a usability risk (such as reducing plunger pullout or syringe cracking) must undergo user validation to confirm the changes do not adversely affect product use [7].

**B. Finding / observation:** Evidence of a simulation or study does not by itself show that each identified critical task was evaluated with suitable users, conditions, and acceptance rationale.

**C. AskDona Assessment perspective:** Distinguish **documentation of a validation activity** from **evidence that the defined critical-task scope was actually covered and evaluated**.

**D. Proposed AskDona solution:** Apply expert-defined criteria for participant/user groups, representative configurations, task coverage, use scenarios, observed use errors and close calls, root-cause discussion, and final human disposition. Map supplied validation documents back to task IDs and flag unclear coverage.

**E. Expected benefit:** Better study-readiness review and earlier identification of missing task-to-test evidence.

**F. Capability boundary:** Sampling sufficiency and study validity are expert determinations; AskDona does not certify protocol adequacy or validation success.

**Fact check (16 Oct 2026, against the linked FDA pages):** **Partly supported.** Medline [7]: “a user validation was not performed to confirm the dimensional changes did not adversely affect use.” That is a deficiency finding, not a stated rule that such changes “must” undergo user validation. Reducing cracked syringes and plunger pullout was the **firm's own** stated purpose for the change, which FDA quotes; calling it a “usability risk” is the analysis's label.

##### Finding 07 — Inconsistent risk methodologies and scales undermine alignment

**A. FDA-derived original insight — verbatim**

> Methodological differences between engineering and usability teams often create inconsistent conclusions across risk documents [5, 13].

**B. Finding / observation:** Inconsistent terminology, severity definitions, risk criteria, or versions of governing SOPs can make related URRA and DFMEA decisions hard to reconcile. Differences can sometimes be justified if the methods have different purposes.

**C. AskDona Assessment perspective:** Check **which approved rules govern each method**, whether deviations or cross-method differences are justified, and whether the final linkage is understandable.

**D. Proposed AskDona solution:** Include the approved risk-management SOP, HF procedure and authorized templates in the evidence set. Configure checks for scale definitions, revision history, rationale, and cross-reference to the governing procedure. Return deviations as potential gaps requiring human confirmation, rather than treating all methodological differences as automatic nonconformities.

**E. Expected benefit:** More consistent reviews and fewer unexplained contradictions between engineering, quality, clinical and regulatory documentation.

**F. Capability boundary:** Rules and numeric calculations must be independently checked or handled in appropriately validated deterministic software; the LLM's free-text response is not a validated risk calculator.

**Fact check (16 Oct 2026, against the linked FDA pages):** **Partly supported.** NeuroSync [5]: the impact and probability scales used to calculate risk are “not adequately defined” within the firm's SOP, and the software risk file does not use RPNs as that procedure requires. iRhythm [13]: health hazard evaluations were not conducted under the firm's risk management SOP. Both are mismatches between a procedure and a risk file, not differences between engineering and usability teams, and neither letter uses “methodology” or “inconsistent”.

##### Finding 08 — Postmarket evidence does not trigger reassessment of use-related risks

**A. FDA-derived original insight — verbatim**

> Risk files (including DFMEAs and URRAs) must be treated as living documents and updated periodically based on customer complaints, competitor recalls, and clinical literature [2, 6, 17].

**B. Finding / observation:** Complaints or field experience may reveal new use errors, previously unrecognized UI contributors, or different observed occurrence patterns while the critical-task justification remains unchanged.

**C. AskDona Assessment perspective:** Treat prior critical-task decisions as documented conclusions with **explicit reassessment triggers**.

**D. Proposed AskDona solution:** At defined review intervals or events, run a controlled checklist checking whether relevant new PMS/complaint and CAPA evidence was considered in URRA, DFMEA, critical-task listings, and HF validation conclusions. Return source-linked discrepancies for expert reassessment.

**E. Expected benefit:** Better closed-loop risk review and improved readiness for audits, design changes and future validation planning.

**F. Capability boundary:** Current documented capabilities support manual/periodic re-execution against curated evidence. Live surveillance, automatic QMS/PLM synchronization and validated delta-impact propagation are not assumed generally available.

**Fact check (16 Oct 2026, against the linked FDA pages):** **Partly supported.** “Periodically”, “competitor recalls” and “clinical literature” are not FDA requirements in any of the letters. The input list including competitor information and published literature is from Beta Bionics' **own SOP** [6]; FDA faulted the omission of post-market complaint, CAPA and nonconformance data from the risk analysis. Philips' procedure [2] called for reviewing competitor experience (MAUDE and recall databases), and FDA faulted the firm for not evaluating an increased severity (death) after a competitor's report. Xoran's [17] own procedures required updating the risk file from complaints, and complaints without a failure investigation were left out. No letter contains the phrase “competitor recalls”.

#### 4. Proposed Operating Model — Unified Human Factors Risk Review

1. **Define the assessment scope.** An expert selects device/version, user group, clinical workflow, relevant tasks, operating environment and governing procedures.
2. **Set controlled criteria.** Human factors, clinical, engineering, quality and regulatory staff agree on task criticality, harm-based rationale, method linkage and validation evidence requirements.
3. **Prepare traceable evidence.** Curate URRA/aFMEA, DFMEA, RMF, use specifications, task analyses, IFU, interface design documents, usability studies, design verification, complaints and CAPA in the permitted RAG repository; preserve revision metadata.
4. **Run first-pass assessment.** Import the expert-authored Excel assessment, use configured metadata/pre-question filters, and retrieve evidence for each criterion.
5. **Inspect gaps and uncertainty.** Review labels, reasons, verbatim evidence and source documents; flag missing evidence and contradictory classifications without equating “not found” with regulatory noncompliance.
6. **Resolve with qualified experts.** Agree whether an apparent duplicate is complementary coverage, an inconsistent decision or a true missing risk; approve critical-task and risk-control dispositions in the controlled system of record.
7. **Reassess on change.** Re-run relevant assessments when the interface, intended use, clinical context, complaints, or approved criteria change.

**Illustrative traceability path:**

```text
Use specification / user group / environment
                  |
               Task ID
                  |
         Potential use error
                  |
    Hazardous situation -> Possible harm
                  |
      URRA ID <----> related DFMEA ID
                  |
           Risk control ID
                  |
       Implementation / verification
                  |
     HF validation task + observation
                  |
      Qualified expert disposition
```

#### 5. Example Assessment Criteria for a Pilot

The following are **illustrative, expert-configured criteria**, not an FDA-approved AskDona template.

<div class="table-scroll">

| ID | Assessment criterion | Evidence to inspect | First-pass gap / uncertainty trigger |
|---|---|---|---|
| HF-01 | Each sampled critical task has a defined user group and use context. | Task analysis, use specification, URRA | User or context missing |
| HF-02 | Criticality has a documented pathway from task error to hazardous situation and potential harm. | URRA, RMF, clinical rationale | “Critical” / “noncritical” without rationale |
| HF-03 | Relevant component or functional failure connections are cross-referenced without requiring identical FMEA/URRA rows. | DFMEA, URRA, hazard register | “Covered in FMEA” without traceable linkage |
| HF-04 | Investigations attributed to user error assess plausible UI and design contributors. | Complaints, CAPA, investigations, design records | Unsupported operator-only root cause |
| HF-05 | Risk controls assigned to critical tasks are identified and linked to requirements. | URRA, specifications, risk-control matrix | Control missing or orphaned |
| HF-06 | Risk-control implementation and verification are documented where applicable. | Design verification, software tests, risk files | No supporting test or implementation evidence |
| HF-07 | HF validation includes evidence for the relevant critical task and conditions of use. | HF protocol, task matrix, test report | Critical task not clearly covered |
| HF-08 | Observed use errors, difficulties and close calls have documented review and disposition. | Participant observations, HF report | Unresolved observation or weak rationale |
| HF-09 | IFU/training-only controls include an approved justification and evaluation of alternatives as required. | Control assessment, IFU, UI documents | Labeling-only conclusion unsupported |
| HF-10 | Risk criteria and terminology are consistent with approved governing procedures, or differences are explained. | SOPs, FMEA/URRA templates, RMF | Unexplained definition or scale mismatch |
| HF-11 | Relevant recent complaints and PMS signals have been considered in critical-task review. | Complaint trends, PMS, URRA revisions | New relevant signal without review |
| HF-12 | Final task and control conclusions have qualified reviewer approval and a controlled record location. | Review minutes, QMS approval records | Only AI output or unsigned draft |

</div>

**Illustrative preliminary output (not a real AskDona execution):**

> `HF-07 | Cannot determine | The available report lists the critical task, but the supplied simulation evidence does not clearly identify a corresponding observed task execution and reviewer disposition. | Evidence: [verified exact excerpt] | Source file: [controlled validation report/version] | Expert action: Locate the missing task evidence or document a justified coverage decision.`

#### 6. AskDona Capability Boundaries

<div class="table-scroll">

| Capability | Evidence-based status | Responsible customer-facing claim |
|---|---|---|
| Excel-based import of assessment criteria and mapping of outputs to Excel | **Documented existing Batch Assessment capability** | Configure repeatable review criteria and export first-pass findings. |
| RAG retrieval, item-level preliminary label, explanation, quoted passage and source-file reference | **Documented existing** | Assemble source-linked evidence for reviewer inspection. |
| Prior questions, document-metadata filtering and configurable inapplicable-item rules | **Documented existing** | Scope review to a selected device or context when documents are properly tagged. |
| “Cannot determine” classification for insufficient evidence | **Configurable existing assessment approach** | Avoid forcing a positive compliance conclusion when evidence is missing. |
| Expert approval and final regulatory/safety responsibility | **Required operating principle, outside autonomous AI decision-making** | Keep final critical-task, clinical-harm and residual-risk judgments with qualified personnel. |
| Automated generation of a complete device-specific critical-task inventory | **Not established** | Pilot as a separately validated future workflow, if desired. |
| Automatic URRA–DFMEA relationship graph or synchronization with eQMS/PLM | **Proposed integration / roadmap** | Validate APIs, permissions, data mapping and lifecycle behavior before claiming. |
| Deterministic end-to-end assessment behavior | **Demonstrated in a constrained research pipeline; not proven for all commercial deployments** | State research feasibility, not universal production repeatability. |
| Proven clinical HF accuracy or a universal time saving | **Not established** | Measure in a device-specific pilot and avoid extrapolating security PoC results. |

</div>

**Important distinction:** AskDona Assessment assists **evidence review against defined criteria**. It should not determine clinical severity, define critical tasks independently, accept residual risks, decide whether a study satisfies FDA expectations, or replace the manufacturer's controlled QMS/PLM records.

#### 7. Suggested Pilot and Expected Benefits

##### 7.1 Pilot scope

- **Scope:** One device family and one representative use workflow, with approximately 15–30 sampled tasks across critical, noncritical, ambiguous and changed-use scenarios.
- **Evidence:** Controlled URRA, DFMEA, RMF, task analysis, UI requirements, IFU, HF validation report, design verification, complaints, and relevant SOPs.
- **Reference standard:** Cross-functional experts define expected task dispositions and evidence requirements before model comparison.
- **Procedure:** Configure 10–12 criteria, test evidence-present and deliberately missing-evidence cases, and compare source quotations and AI outputs with expert adjudication.
- **Records:** Log reviewer approvals and remediation actions in the established QMS; use AskDona as a source-linked preliminary reviewer.

##### 7.2 KPIs — proposed measurements, not established results

<div class="table-scroll">

| KPI | Measurement | Expected directional benefit |
|---|---|---|
| Critical-task rationale coverage | % sampled tasks with reviewed harm pathway | Higher coverage and fewer unsupported classifications |
| Cross-method linkage | % relevant URRA entries with appropriate DFMEA relationship or justified separation | Fewer orphaned / contradictory records |
| Validation traceability | % sampled critical tasks with verifiable validation evidence and disposition | Better submission and audit readiness |
| Source citation accuracy | % generated citations verified against controlled files | More trustworthy review packets |
| False assurance rate | % unsupported claims incorrectly assessed as satisfied | Lower false reassurance |
| Expert review effort | Review minutes per task compared with manual baseline | Reduced evidence-search overhead |
| Postmarket reassessment coverage | % pertinent new events assessed against existing task/risk conclusions | More timely follow-up |

</div>

##### 7.3 Expected organizational impact

A successfully validated deployment could shorten repetitive document searching, impose a shared evidence-review structure across human factors and engineering, reveal unsupported critical-task decisions earlier, and generate more reviewable links between risk controls and validation outcomes. These are **anticipated** outcomes, not quantified product performance claims for this use case. Any GxP/QMS deployment requires appropriate intended-use validation, access management and documented expert review.

#### 8. FDA-Related URLs — Copyable Markdown Links

The numbering follows the **supplied FDA-derived analysis**. These links are included as full destinations for later copy/paste; **[Outdated — marked 2026-10-16]** the case-specific interpretations above have **not been independently verified against every FDA document**. **Updated (16 Oct 2026):** all 15 linked FDA pages were opened and each insight and finding checked; the result is given as a “Fact check” note. Firm names, letter numbers and dates match. Pages marked *Inspection Guide* are not Warning Letters.

- **[1] [EMC MDQS Page 5 — FDA Inspection Guide](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/inspection-guides/emc-mdqs-page-5)** — Information for safety versus technical controls.
- **[2] [Royal Philips — 709948 — 09/09/2025](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/royal-philips-709948-09092025)** — Product requirement and risk traceability.
- **[4] [Unilam Co., LTD — 738562 — 09/22/2026](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/unilam-co-ltd-738562-09222026)** — Design controls versus warning-focused mitigations.
- **[5] [NeuroSync, Inc. — 705489 — 05/09/2025](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/neurosync-inc-705489-05092025)** — Risk method and criteria consistency.
- **[6] [Beta Bionics, Inc. — 717927 — 01/28/2026](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/beta-bionics-inc-717927-01282026)** — Investigation of use error and design contributors.
- **[7] [Medline Industries, LP — 677545 — 03/18/2024](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/medline-industries-lp-677545-03182024)** — Device modifications and use-related considerations.
- **[8] [Zyno Medical LLC — 629844 — 07/12/2022](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/zyno-medical-llc-629844-07122022)** — Human factors simulation practices.
- **[9] [Anigan, Inc. — 557163 — 07/25/2018](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/anigan-inc-557163-07252018)** — Risk and validation evidence.
- **[10] [Beckman Coulter Inc. — 678042 — 03/15/2024](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/beckman-coulter-inc-678042-03152024)** — Clinical harm from delayed diagnostic workflows.
- **[13] [iRhythm Technologies, Inc. — 643474 — 05/25/2023](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/irhythm-technologies-inc-643474-05252023)** — Risk calculation and methodology differences.
- **[17] [Xoran Technologies, LLC — 694229 — 12/09/2024](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/xoran-technologies-llc-694229-12092024)** — Postmarket feedback into risk review.
- **[19] [Medtronic, Inc. — 617539 — 12/09/2021](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/medtronic-inc-617539-12092021)** — Severity and probability rationale.
- **[20] [Koven Technologies, Inc. — 734643 — 07/21/2026](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/koven-technologies-inc-734643-07212026)** — Use-related hazard involving fetal heart rate interpretation.
- **[21] [Becton, Dickinson, and Company/CareFusion 303, Inc. — 691601 — 11/22/2024](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/becton-dickinson-and-companycarefusion-303-inc-691601-11222024)** — Time-sensitive access and device performance consequences.
- **[22] [WHOOP, Inc. — 709755 — 07/14/2025](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/whoop-inc-709755-07142025)** — Potential consequences of misleading measurements.

**Fact check (16 Oct 2026, against the linked FDA pages):** None of the 15 sources uses “URRA”, “use-related risk” or “human factors validation”; “critical tasks” appears only in Zyno [8], quoting the firm's SOP. [1], [2], [5], [10], [13], [17], [19] and [22] have no human-factors content and support only general risk-management points. Descriptions to correct: [1] concerns electromagnetic interference labeling only; [5] concerns scales not defined in the firm's SOP; [10] concerns severity misrated for false or delayed results (“workflow” is not in the letter); [20]'s core finding is fetal risks missing from the risk files after an indications change; [22] is an unapproved-device letter about measurement accuracy and says “erroneous”, not “misleading”. [21] (BD/CareFusion Pyxis dispensing delays) is listed but not cited in the text. Zyno [8], Anigan [9] and Beckman Coulter [10] were issued by FDA field offices; the others by CDRH.

---

**Positioning statement:** *AskDona Assessment can help medical device teams identify where critical use task determinations, URRA–DFMEA connections, usability controls, and validation evidence are insufficiently supported or inconsistent. It provides criteria-based, source-linked preliminary evidence reviews; qualified human factors, clinical, engineering and regulatory experts remain responsible for critical-task judgments and approved risk records.*