# Maintaining risk and design traceability through change

> Design controls can become disconnected when risk analyses, user needs, design inputs, and verification results are maintained separately. When a design changes, associated assessments may not be updated consistently, leaving incomplete traceability between risk controls and evidence of their effectiveness. These gaps can require extensive reconstruction of design history and risk rationales ahead of regulatory submissions or audits.

- Status: Current. Last verified 2026-10-15.
- Applies to: Qualitative synthesis of 17 public practitioner discussions, October 2026. Not facts about AskDona, verified audit findings or prevalence statistics.
- Canonical: https://askdona.com/ai/assessment-challenge-03-risk-design-traceability-through-change.md

03

**Category: CONTROL | Subcategory: Change**

Assessment area: Risk Assessment / Design

Design controls can become disconnected when risk analyses, user needs, design inputs, and verification results are maintained separately. When a design changes, associated assessments may not be updated consistently, leaving incomplete traceability between risk controls and evidence of their effectiveness. These gaps can require extensive reconstruction of design history and risk rationales ahead of regulatory submissions or audits.

As product designs evolve, the documents that describe user needs, design inputs, failure modes, controls, and verification results may be updated in different systems by different teams. A change can therefore be reflected in a drawing or requirement without prompting a corresponding reassessment in the FMEA or risk management file. Individual documents may appear complete even when the overall design-control evidence no longer tells a consistent story.

Practitioners described the accumulation of this documentation debt as especially costly before regulatory submissions, when teams are forced to reconstruct why a particular requirement was chosen or how a control was tested. The problem is not limited to missing hyperlinks: a trace may exist but point to an outdated requirement, an unapproved revision, or evidence that does not test the current implementation.

The core challenge is to maintain traceable relationships and change-triggered assessment responsibilities throughout development, rather than rebuilding the logic only when an auditor or submission deadline demands it.

---

## AskDona Assessment — Maintaining Risk and Design Traceability Through Change

**Topic 03 | CONTROL — Change**  
**Assessment area:** Risk Assessment / Design  
**Challenge status:** Current · verified 2026-10-15  
**Document prepared:** 2026-10-16  
**Focus:** Evidence-based change-impact review across user needs, design inputs and outputs, risk management, risk controls, verification/validation (V&V), and design history.

> **Interpretation and evidence boundary:** Section 1 reproduces the challenge verbatim. The excerpts in Section 2 and in the finding-by-finding analysis reproduce wording from the **user-supplied analytical summary of FDA-related material**, not verbatim text taken from FDA Warning Letters. **[Outdated — marked 2026-10-16]** The FDA links at the end are supplied case links for subsequent checking; this report does not claim independent verification of every case-specific characterization. **Updated (16 Oct 2026):** all 20 linked FDA letters were opened and each Section 2 insight checked; the result is given as a “Fact check” note. AskDona Assessment supports **preliminary, evidence-linked reviews**; it does not approve design changes, determine regulatory submission obligations, or replace the controlled QMS/PLM system or qualified personnel.

### 1. Original Challenge — Verbatim

#### 1.1 Title and classification

**Maintaining risk and design traceability through change**  
**Current · verified 2026-10-15 · 03**  
**Category:** CONTROL | **Subcategory:** Change  
**Assessment area:** Risk Assessment / Design

#### 1.2 Original summary

> Design controls can become disconnected when risk analyses, user needs, design inputs, and verification results are maintained separately. When a design changes, associated assessments may not be updated consistently, leaving incomplete traceability between risk controls and evidence of their effectiveness. These gaps can require extensive reconstruction of design history and risk rationales ahead of regulatory submissions or audits.

#### 1.3 Full original discussion

> As product designs evolve, the documents that describe user needs, design inputs, failure modes, controls, and verification results may be updated in different systems by different teams. A change can therefore be reflected in a drawing or requirement without prompting a corresponding reassessment in the FMEA or risk management file. Individual documents may appear complete even when the overall design-control evidence no longer tells a consistent story.
>
> Practitioners described the accumulation of this documentation debt as especially costly before regulatory submissions, when teams are forced to reconstruct why a particular requirement was chosen or how a control was tested. The problem is not limited to missing hyperlinks: a trace may exist but point to an outdated requirement, an unapproved revision, or evidence that does not test the current implementation.
>
> The core challenge is to maintain traceable relationships and change-triggered assessment responsibilities throughout development, rather than rebuilding the logic only when an auditor or submission deadline demands it.

#### 1.4 Consolidated issue and implications

The central failure is **loss of integrity in the evidence chain**, rather than merely missing cross-references. A trace can be present but still be unreliable if the requirement, revision, risk-control implementation, or test configuration is no longer the applicable one. A defensible change review should identify **what changed, what could be affected, what evidence still applies, what must be reassessed, who reviewed it, and where the approved disposition is recorded**.

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

The following passages are reproduced from the supplied FDA-related analysis **as analytical text, not direct FDA quotations**. Bracketed numbers follow that analysis and correspond to the full URLs in Section 9.

#### 2.1 Requirements introduced without updating formal design inputs

> A major risk during a design change is implementing modifications or new requirements during the verification phase without back-propagating them into the design inputs. For example, during a design change, a firm might complete verification testing for newly identified requirements designed to mitigate a specific failure mode, yet fail to add these requirements to the official design input documentation [14]. This results in a design history file (DHF) where the design outputs and verification reports do not align with the approved inputs [14, 19]. In other instances, organizations fail to maintain updated specifications, leading to DHFs that refer to outdated product models [8].

**Fact check (16 Oct 2026, against the linked FDA letters):** **First sentence supported; the rest partly.** Beckman Coulter [14] (DxI 9000 immunoassay; issued by an FDA field office): requirements identified in a verification by analysis and inspection to mitigate a failure mode “were not added to the design input documentation”. Primus / Trinity Biotech [19]: design verification “does not demonstrate that your design outputs meet all inputs”; neither letter uses “DHF” or “approved inputs”. NeuroSync [8]: the outdated reference to the replaced Model X02 is in the **Design Input Requirements document**, not a DHF.

#### 2.2 Permanent design changes routed as deviations

> To accelerate timelines, some manufacturers attempt to bypass formal design change processes. A common nonconformance involves routing permanent changes to a product's fit, form, or function through temporary manufacturing deviation procedures rather than the formal design change control system [13]. Doing so typically skips the required design verification, validation, and risk assessments, leaving the manufacturer with no objective evidence that the change did not adversely affect the finished device [13]. Similarly, firms often implement dozens of undocumented design changes (such as modifications to labeling or components) without formal change records or impact assessments [4, 10].

**Fact check (16 Oct 2026, against the linked FDA letters):** **Micro-X supported; “dozens” not supported.** Micro-X [13] (Rover mobile X-ray): multiple design changes to fit, form or function were processed under a manufacturing-deviation SOP “intended for temporary deviations”, without verification or validation results; “permanent”, “risk assessment” and “objective evidence” are the analysis's additions. CellEra [4]: the number of undocumented design changes (instructions, storage, shelf life) is **redacted**. Nipro [10]: five listed changes (packaging, film thickness, endotoxin specifications, not labeling) lacked change records; impact assessments appear only as the firm's commitment.

#### 2.3 Static risk analyses despite new signals

> When critical quality events occur—such as Class I recalls [10], labeling failures [17], or a significant increase in postmarket complaints [9, 11, 17, 18]—manufacturers often fail to update their risk management files to evaluate these newly recognized hazards. This disconnect severely compromises the quality unit's ability to ensure that the device's clinical benefits continue to outweigh its risks [18].

**Fact check (16 Oct 2026, against the linked FDA letters):** **Partly supported.** Nipro [10] (hemodialysis concentrates; letter dated 16 July 2026) did not update its risk analysis since 2020 despite an ongoing Class I recall (one recall, not several). Meridian [17]: risk files not updated after an increase in false-positive complaints and after labeling failures. Beta Bionics [9] and Xoran [18] concern post-market data and complaints not fed into risk files, without a described complaint increase. Medline [11] **does not fit**: its DFMEA gap relates to a design change, not complaints. The sentence on the quality unit's ability to ensure benefits outweigh risks is the analysis's own; it is not in [18].

#### 2.4 Regression and verification/validation impact

> When executing an Engineering Change Order (ECO), design change procedures must explicitly require an evaluation of how the change impacts previous V&V tests [5]. Bypassing validation or verification testing is only acceptable if a comprehensive, documented justification is provided [5, 11].

> Furthermore, software and firmware updates are frequently pushed to production without documenting batch records or verifying that unchanged, potentially affected portions of the software have not been disrupted, creating a systemic gap in the ability to detect regression failures [15].

**Fact check (16 Oct 2026, against the linked FDA letters):** **Partly supported; the justification rule is the firms' own.** Q'Apel [5]: the firm “has not evaluated the impact changes may have to original verification or validation tests” (ECO 1142, ECO 1360). That skipping V&V is acceptable with a documented justification comes from the **firms' own SOPs** (Q'Apel, Medline [11]); FDA rejected the justifications given in both letters. Pensar [15]: no batch record demonstrated a firmware change's implementation, and the software validation procedure “does not address the need to confirm that unchanged but potentially affected portions of the software have not been inadvertently disrupted”; “pushed to production” is the analysis's phrase.

#### 2.5 Retrospective compilations and lost design history

> **The Inadequacy of Retroactive "Compilations":** Some firms attempt to address a missing design history by retroactively assembling a "Design History Compilation" [16]. However, regulatory authorities do not accept a mere compilation of records as a substitute for establishing and maintaining appropriate design control processes throughout development [16]. Retroactive DHF reconstruction programs are highly resource-intensive and often fail to demonstrate that the initial design was developed under a controlled state [7, 10, 12].

> **The Vulnerability of Institutional Knowledge:** Relying on informal systems or paper records poses severe business continuity risks. In one documented instance, a manufacturer was entirely unable to locate its original design history files because the single employee responsible for storing them had retired, forcing the company to attempt to track down the retiree in retirement to find the files [1]. This highlights how critical it is to maintain centralized, validated, and secure electronic design control systems.

**Fact check (16 Oct 2026, against the linked FDA letters):** **Compilation and retired-employee points supported; the reconstruction sentence is not.** ITL Asia Pacific [16]: “A Design History Compilation cannot take the place of demonstrating compliance to design controls.” The claim that retroactive reconstruction is resource-intensive and fails to demonstrate a controlled state appears in none of [7], [10] or [12]: TELEMED's and Nipro's retroactive DHF programs were **firm proposals** whose adequacy FDA could not yet judge, and Jiangsu Shenli is noted only for lacking retrospective-analysis results. Abbott Point of Care [1] (i-STAT cartridge) could not locate original design files because “the person in charge of storing” them had retired, and was trying to locate that person.

#### 2.6 Risk-control traceability, cumulative change, and feedback

> A compliant Design Traceability Matrix (DTM) must go beyond linking requirements to test cases. It should integrate risk controls directly into the requirements flow. Best-in-class procedures update the DTM by assigning unique Risk Control IDs to specific risk control measures and mapping them directly to relevant Product Requirement Specification IDs [2]. This ensures that every risk control is verified and that no requirement is modified without evaluating its impact on safety.

> As product designs evolve, multiple minor changes can combine to significantly alter the device's safety or performance. Procedures should mandate a *cumulative review* of all design changes made over the device's lifecycle [1, 20]. This review helps determine whether the cumulative effect of these modifications has altered the device's clinical accuracy, safety, or intended use to the point that a new premarket regulatory submission (such as a new 510(k)) is required [1, 20].

> Customer complaints, field failures, and unanticipated clinical events must be systematically reviewed [9, 18]. If an unanticipated event occurs, the procedure should trigger a review of prior Design Verification Testing (DVT) to verify whether the previously established risk mitigations are still effective, updating the dFMEA accordingly [9].

**Fact check (16 Oct 2026, against the linked FDA letters):** **Partly supported.** The Design Traceability Matrix, Risk Control IDs and “best-in-class” wording are not FDA's: assigning risk-control IDs mapped to product requirement IDs was **Philips' own corrective action** [2], and FDA noted the updated matrix had not been provided to verify it. On cumulative review, Abbott [1] was asked to revise procedures to address “the need for a cumulative review of design changes” and Kabe [20] was told cumulative changes “should be assessed to determine if a new 510(k) is needed”; these are case-specific requests, not a general mandate. The DVT review after unanticipated events is the **firm's own SOP** quoted in Beta Bionics [9]; Xoran [18] did not risk-assess a complaint to decide whether its FMEA needed updating.

### 3. Detailed Findings — Regulatory Observation, AskDona Perspective, Solution and Benefit

The following eight findings map the challenge and the supplied FDA-derived analysis to **configurable AskDona Assessment workflows**. Assessments should be administered against expert-authored, product- and process-specific criteria rather than treating the AI's suggested links as established compliance facts.

#### Finding 01 — “Phantom” Requirements and Broken Input–Output–Test Alignment

**(A) Original FDA-derived insight**

> A major risk during a design change is implementing modifications or new requirements during the verification phase without back-propagating them into the design inputs. For example, during a design change, a firm might complete verification testing for newly identified requirements designed to mitigate a specific failure mode, yet fail to add these requirements to the official design input documentation [14].

**(B) Finding / issue:** A new test or design output can exist without a current, approved corresponding design input; apparently complete DHF documents may disagree on requirement identity or revision.

**(C) AskDona Assessment perspective:** Assess *relationship integrity and revision applicability*, not simply whether a document contains a matching keyword or ID.

**(D) Proposed AskDona solution:** Configure checklist items requiring the changed feature to be linked to approved user needs, input ID/revision, output specification, risk-control ID (where applicable), and V&V reference. Search controlled inputs, specifications, change records, test protocols/reports and the traceability matrix. Return a preliminary label, explanation, cited passages and source files; flag absent links or conflicting revisions for expert adjudication.

**(E) Expected benefit:** Earlier discovery of missing or stale requirements, reduced last-minute DHF reconstruction, and clearer evidence for submission reviewers.

**(F) Capability boundary:** Cross-document evidence retrieval and criterion-level assessment are documented capabilities. Automatic creation/maintenance of authoritative traceability relationships in PLM or QMS is **not established**.

#### Finding 02 — Permanent Changes Hidden in Temporary Deviations

**(A) Original FDA-derived insight**

> A common nonconformance involves routing permanent changes to a product's fit, form, or function through temporary manufacturing deviation procedures rather than the formal design change control system [13].

**(B) Finding / issue:** A deviation or exception may conceal a permanent design change without formal impact review or approved disposition.

**(C) AskDona Assessment perspective:** Evaluate whether the actual implemented change and its lifecycle disposition agree with the route used to authorize it.

**(D) Proposed AskDona solution:** Review deviation records, ECOs, released drawings, BOMs, software revision logs and SOPs against defined decision criteria: Was the change temporary? Was the permanent configuration approved? Was risk/V&V impact assessed or explicitly justified? Flag documentation gaps and contradictory descriptions.

**(E) Expected benefit:** More consistent routing to the correct change-control process and visibility into exceptions that merit escalation.

**(F) Capability boundary:** AskDona can assess supplied records; it does not itself enforce workflow routing, block manufacturing release, or confer change approval authority.

#### Finding 03 — FMEA and RMF Not Reassessed After Design or Postmarket Changes

**(A) Original FDA-derived insight**

> When critical quality events occur—such as Class I recalls [10], labeling failures [17], or a significant increase in postmarket complaints [9, 11, 17, 18]—manufacturers often fail to update their risk management files to evaluate these newly recognized hazards.

**(B) Finding / issue:** New information may invalidate original probability assumptions, hazard coverage, or risk-control assumptions while older assessments remain unchanged.

**(C) AskDona Assessment perspective:** Treat prior risk judgments as conclusions that require review at defined triggers, not as immutable labels.

**(D) Proposed AskDona solution:** At a periodic or manually initiated change review, compare the supplied complaints/CAPA/recall summaries, change records and current risk files against expert-defined reassessment criteria. Identify whether each relevant signal has a linked review, rationale and documented disposition. Use `Cannot determine` for missing or conflicting evidence rather than declaring the risk acceptable.

**(E) Expected benefit:** Better postmarket-to-design feedback, fewer unreviewed assumptions, and a reviewable reassessment history.

**(F) Capability boundary:** Configured repeated execution is feasible. Real-time connector-driven signal monitoring, guaranteed change-trigger automation and deterministic incremental reassessment are not demonstrated as generally available.

#### Finding 04 — Missing Regression and V&V Impact Justification

**(A) Original FDA-derived insight**

> When executing an Engineering Change Order (ECO), design change procedures must explicitly require an evaluation of how the change impacts previous V&V tests [5]. Bypassing validation or verification testing is only acceptable if a comprehensive, documented justification is provided [5, 11].

**(B) Finding / issue:** An existing test may no longer verify the changed implementation, even when the historical test report remains accessible.

**(C) AskDona Assessment perspective:** Test traceability must include *configuration, revision, scope and justification for reuse*, not only a test-case identifier.

**(D) Proposed AskDona solution:** Assess whether an ECO identifies affected requirements, prior V&V coverage, changed subsystems, regression scope, test article/software version, and a documented rationale for retained or omitted testing. Return cited proof or an evidence gap for reviewer action.

**(E) Expected benefit:** More targeted regression planning and fewer cases of citing obsolete test evidence as support for the current design.

**(F) Capability boundary:** AskDona does not execute engineering tests, verify a physical control's performance, or autonomously determine adequate regression coverage.

#### Finding 05 — Missing Risk-Control IDs or Unsupported Design-to-Control Links

**(A) Original FDA-derived insight**

> A compliant Design Traceability Matrix (DTM) must go beyond linking requirements to test cases. It should integrate risk controls directly into the requirements flow. Best-in-class procedures update the DTM by assigning unique Risk Control IDs to specific risk control measures and mapping them directly to relevant Product Requirement Specification IDs [2].

**(B) Finding / issue:** Requirement and test links may exist while the hazard, control measure, control implementation and verification evidence are unconnected or inconsistent.

**(C) AskDona Assessment perspective:** Inspect a traceability chain as a set of independently verifiable assertions: requirement → hazardous situation → risk-control measure → implemented output → verification/validation → residual-risk review.

**(D) Proposed AskDona solution:** Import expert-defined traceability criteria from Excel and query the risk-management file, requirements, risk-control matrix and V&V records. Assess presence of IDs, revision alignment and cited support; present missing edges and contradictory text for human follow-up.

**(E) Expected benefit:** Stronger risk-control evidence packages and reduced time explaining the relationship between design decisions and tests.

**(F) Capability boundary:** Source-linked item review is available; comprehensive automated graph creation and guaranteed completeness of all risk-control paths are integration/research objectives, not established production guarantees.

#### Finding 06 — “Cosmetic” or “No Safety Impact” Conclusions Without Rationale

**(A) Original FDA-derived insight**

> This prevents teams from bypassing risk assessments by falsely claiming that a change (such as a software update or structural casing change) is merely "cosmetic" or unrelated to safety without documented justification tied directly to the dFMEA [2, 15].

**(B) Finding / issue:** A reassuring change category may be asserted without documenting the analysis of safety, effectiveness, user interaction or adjacent functions.

**(C) AskDona Assessment perspective:** Review the rationale for “no impact” as a standalone evidence requirement; do not equate classification text with proof.

**(D) Proposed AskDona solution:** Use a checklist to confirm the selected change has a reviewed impact statement, cited product-specific facts, relevant hazard/FMEA entries, applicable approvals and a controlled record location. Flag unsupported or circular justifications.

**(E) Expected benefit:** Fewer silent omissions and a more defensible distinction between truly non-impactful changes and cases requiring additional testing or risk review.

**(F) Capability boundary:** Final regulatory/safety significance remains a qualified person's responsibility; AskDona cannot certify that a change is cosmetic.

**Fact check (16 Oct 2026, against the linked FDA letters):** **Pensar supported; Philips partly.** Pensar [15]: the firm called a redacted noise change in a firmware ECO “cosmetic in nature” and unrelated to safety or effectiveness, without a documented risk assessment tied to the design FMEA. Philips [2]: new ISCV 8.0 requirements were marked “no safety risk” with no justification, but “cosmetic” does not appear and the document was a risk management matrix. “Structural casing change” appears in neither letter.

#### Finding 07 — Cumulative Effects of Individually Minor Changes

**(A) Original FDA-derived insight**

> As product designs evolve, multiple minor changes can combine to significantly alter the device's safety or performance. Procedures should mandate a *cumulative review* of all design changes made over the device's lifecycle [1, 20].

**(B) Finding / issue:** Individually justified change decisions may become inconsistent with the current product configuration when assessed in isolation.

**(C) AskDona Assessment perspective:** Make the *declared change history and cumulative-review rationale* explicit assessment inputs.

**(D) Proposed AskDona solution:** Supply the approved ECO history, baseline/current specifications and associated risk reviews in the evidence repository. Configure criteria verifying that the cumulative impact was considered and the rationale documented. AskDona can return potentially conflicting statements for a design/regulatory review board.

**(E) Expected benefit:** More complete design-evolution narratives and earlier escalation of unresolved cumulative change questions.

**(F) Capability boundary:** Automatic exhaustive engineering dependency analysis and determination of whether a new 510(k) is required are not supported claims.

#### Finding 08 — Retrospective DHF Reconstruction and Institutional Knowledge Loss

**(A) Original FDA-derived insight**

> **The Inadequacy of Retroactive "Compilations":** Some firms attempt to address a missing design history by retroactively assembling a "Design History Compilation" [16]. However, regulatory authorities do not accept a mere compilation of records as a substitute for establishing and maintaining appropriate design control processes throughout development [16].

> **The Vulnerability of Institutional Knowledge:** Relying on informal systems or paper records poses severe business continuity risks.

**(B) Finding / issue:** Scattered records create avoidable reconstruction work and may leave the actual contemporaneous approval or design decision unprovable.

**(C) AskDona Assessment perspective:** Distinguish “document discovered” from “contemporaneous controlled evidence established.”

**(D) Proposed AskDona solution:** Index provided controlled DHF/QMS/PLM document exports and run evidence-existence criteria for a sampled design history. Return the exact supporting quotation/file for each item or `Cannot determine` for absent approvals, revision states or historical reasoning. Export a remediation checklist for the system of record.

**(E) Expected benefit:** Reduced manual document hunting, clearer gaps in retained decision history, and less dependence on individual recollection.

**(F) Capability boundary:** AskDona cannot recreate authentic missing approvals, retroactively establish historical compliance, or substitute for contemporaneous design-control procedures.

### 4. Proposed AskDona Operating Model — Change-Triggered Evidence Assessment

1. **Set the assessment boundary:** Device family, configuration, change/ECO identifier, impacted subsystem, intended use, baseline/current revision, and effective dates.
2. **Define criteria with experts:** Quality, design engineering, risk management, clinical/human factors and regulatory owners specify which links and justifications must exist under approved procedures.
3. **Assemble controlled evidence:** Select the relevant RAG repository containing versioned user needs, requirements, outputs, drawings/BOMs, risk files, change records, test plans/results, complaints/CAPA and approval records.
4. **Scope the assessment:** Use available intake questions and metadata filters to focus on the correct device, project or revision, and exclude clearly inapplicable checklist items under explicit rules.
5. **Generate preliminary assessments:** For each item AskDona returns a configurable result label, explanatory comment, supporting quotation and referenced file. Preserve `Cannot determine` when the supplied evidence is insufficient.
6. **Conduct qualified human review:** Reviewers inspect the cited authoritative source, resolve conflicts, assess actual technical impact, assign corrective actions and approve the controlled disposition in the existing system of record.
7. **Repeat at review gates:** Re-execute the appropriate checklist when a new controlled change package or postmarket input becomes available. Save and compare exported records through a controlled procedure; automated data syncing and delta detection require specific integration/validation.

#### Recommended evidence relationship

```text
User Need / Intended Use
         ↓
Approved Design Input (ID + revision)
         ↓
Design Output / Implementation (configuration + revision)
         ↘
       Hazard / Risk Analysis (FMEA / RMF)
         ↓
Risk Control (ID + implementation)
         ↓
Verification / Validation (test + article/version + outcome)
         ↓
Change Impact Rationale + Authorized Human Approval
         ↘
Complaint / CAPA / Postmarket Signal → Reassessment Trigger
```

*This is an assessment schema, not a claim that AskDona currently creates or maintains this entire graph automatically.*

### 5. Illustrative Assessment Checklist for a Pilot

The criteria below are **proposed configuration content**, not confirmed built-in AskDona templates or a complete regulatory checklist.

<div class="table-scroll">

| ID | Expert-defined assessment criterion | Evidence to inspect | Preliminary exception/uncertainty trigger |
|---|---|---|---|
| CH-01 | The change identifies the affected product, baseline/current configuration and effective revision. | ECO, BOM, drawing, release log | Mixed or missing revisions |
| CH-02 | Each changed or newly tested requirement appears in approved design inputs. | Requirement baseline, protocol, design review | Test-only “phantom” requirement |
| CH-03 | Relevant user needs remain linked to current design inputs and outputs. | Needs matrix, DHF, specifications | Orphan input/output |
| CH-04 | The change route is consistent with whether the modification is temporary or permanent. | Deviation, ECO, change SOP | Permanent implementation under temporary deviation |
| CH-05 | The FMEA/RMF impact evaluation addresses the affected design and use conditions. | dFMEA, uFMEA, RMF, ECO | Risk analysis not revised or justified |
| CH-06 | Changed or affected risk controls are identified by controlled IDs. | Risk-control matrix, requirements | Control exists without traceable ID |
| CH-07 | Verification evidence applies to the current implemented configuration. | DVT report, test article/version, drawing | Obsolete test article or protocol |
| CH-08 | Regression/V&V impact is documented, including rationale for tests not repeated. | ECO impact checklist, V&V plan | Missing justification |
| CH-09 | Postmarket inputs relevant to the change were considered. | Complaints, CAPA, vigilance review | Known signal without documented review |
| CH-10 | The cumulative effect of related recent changes was considered where applicable. | ECO history, change board minutes | Isolated decisions without cumulative review |
| CH-11 | “Cosmetic/no impact” claims are supported by a recorded product-specific rationale. | ECO, safety review, RMF | Bare classification without evidence |
| CH-12 | A qualified authorized reviewer approved the final impact disposition in a controlled system. | Approval record, QMS history | Draft-only or unsigned decision |

</div>

**Illustrative preliminary output (hypothetical):**

```text
Criterion: CH-07
Preliminary label: Cannot determine
Comment: The verification report identifies software version 2.3,
         while the change record describes implementation in version 2.4.
         No approved regression rationale supporting reuse was found
         in the supplied evidence.
Evidence: [verbatim excerpt from the source document]
Reference: [controlled file name / revision]
Expert action: Confirm the approved test configuration and whether
               additional verification or a documented justification is needed.
```

### 6. Capability Boundaries — Present, Research, and Proposed

<div class="table-scroll">

| Capability | Evidence-supported status | How to position it |
|---|---|---|
| Excel import of predefined assessment items | **Documented current Batch Assessment / AskDona Assessment capability** | Configure an expert-defined design-change assessment checklist. |
| RAG-based document retrieval | **Documented current** | Retrieve relevant source passages from the selected evidence repository. |
| Per-item preliminary result, comment, quotation and source file | **Documented current** | Prepare an evidence-linked first-pass review for expert checking. |
| Pre-run questions and metadata-based scoping | **Documented current** | Focus the evidence search by device/project when records are properly tagged. |
| Configurable `Cannot determine` outcome | **Documented configurable pattern** | Distinguish insufficient evidence from verified nonconformance. |
| Export reviewed preliminary assessments to Excel | **Documented current** | Supply a review artifact for a controlled downstream process. |
| API/MCP/OEM embedding into eQMS/PLM | **Strategy / integration design; exact production interfaces unconfirmed** | Scope and validate with the partner. |
| Automatic authoritative bidirectional traceability graph | **Not established** | Future integration or tailored workflow, not an out-of-box promise. |
| Autonomous change-impact propagation and continuous postmarket triggers | **Not established as general release** | Require source integration, explicit rules, verification and governance. |
| Byte-identical deterministic end-to-end replay | **Demonstrated in a specific research pipeline and test conditions, not universal production behavior** | Research feasibility, not a blanket platform guarantee. |
| Regulatory determination, risk acceptance, design release or new 510(k) decision | **Reserved for qualified personnel** | Human-approved QMS/PLM disposition remains authoritative. |

</div>

The research program emphasizes reproducibility across document extraction, embedding, retrieval, inference and recorded quotations; it is **not evidence that every deployed AskDona Assessment instance already has these deterministic controls**. Reproducibility itself is distinct from accuracy and regulatory validation.

### 7. Suggested Pilot and Measurement Plan

**Pilot scope:** One device family and 10–20 real ECOs (include software and hardware changes, cases with no-risk-impact conclusions, change-deviation exceptions and at least one complaint-triggered review). Sample 30–60 link-level assessment questions distributed across requirements, risk, V&V and approval criteria.

**Comparison:** Use blinded expert adjudication of the same controlled source set. Compare AskDona-assisted evidence reviews with the team's current document search and reconciliation process; review the citations, not only labels.

<div class="table-scroll">

| Measure | Definition / method | Expected directional effect (not a proven result) |
|---|---|---|
| Evidence retrieval precision | Percentage of sampled citations verified as relevant to the criterion | Higher usable evidence quality |
| Broken-link detection | Expert-confirmed missing/stale connections detected / seeded or adjudicated gaps | More complete gap detection |
| Revision applicability | Percentage of accepted links pointing to correct controlled revisions | Fewer obsolete references |
| False assurance rate | Unsupported conditions incorrectly classified as satisfied | As low as practicable |
| Assessment effort | Reviewer and document-hunting minutes per ECO | Lower repetitive labor |
| V&V impact coverage | Percentage of change packages with evidence for test/retest rationale | More complete review packages |
| Disposition traceability | Percentage of issues with owner, expert decision, approval and destination | Stronger audit readiness |
| Change/re-run stability | Label, quoted passage and source-file agreement on unchanged controlled input | Measurable reproducibility |

</div>

**Success conditions:** No autonomous approvals; a pre-agreed expert review protocol; validation for intended use; revision-controlled source data; a documented escalation rule for unsupported conclusions; defined access and retention controls.

### 8. Expected Organizational Benefits and Positioning

- **Reduce documentation debt:** Shift from pre-submission evidence reconstruction toward repeatable, criterion-based checks at change review gates.
- **Strengthen explainability:** Provide source-linked preliminary reasons for why a requirement, control or test appears to support a change decision.
- **Surface stale evidence sooner:** Highlight revision conflicts and unsupported reuse of historical V&V results, subject to expert confirmation.
- **Coordinate teams:** Give design, QA, risk, human factors and regulatory reviewers a common evidence-centered checklist while preserving their specialized decision authority.
- **Improve audit and submission preparation:** Produce more reviewable evidence packages, without presenting a generated report as a substitute for contemporaneous controlled records.
- **Retain existing systems of record:** Position AskDona as an assessment/evidence review layer alongside QMS/PLM/ALM rather than as a replacement for their approvals and records.

**Positioning statement:** *AskDona Assessment helps medical-device teams maintain the integrity of design and risk evidence through change by assessing expert-defined traceability and V&V criteria against controlled, product-specific records. It surfaces gaps, outdated references and unsupported conclusions for qualified review; final design-control and regulatory decisions remain human-owned.*

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

**[Outdated — marked 2026-10-16]** The references below retain the numbering used in the **supplied FDA analytical example**; the source-specific descriptions in that example should be verified against the underlying FDA pages before external publication. **Updated (16 Oct 2026):** all 20 linked FDA letters were opened and each Section 2 insight checked; the result is given as a “Fact check” note. Firm names and letter numbers match; Nipro [10] is dated 16 July 2026 (24 July is the posting date in the URL). [3] International Hospital Products and [6] MiBo Medical are listed but not cited in the text. FDA inspection guides and Warning Letters are not interchangeable types of authority. Full URLs are embedded directly in each Markdown link.

1. [Abbott Point of Care Canada Limited — Warning Letter 640946 (2022-11-08)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/abbott-point-care-canada-limited-640946-11082022)
2. [Royal Philips — Warning Letter 709948 (2025-09-09)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/royal-philips-709948-09092025)
3. [International Hospital Products, Inc. — Warning Letter 579332 (2019-05-29)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/international-hospital-products-inc-579332-05292019)
4. [CellEra LLC — Warning Letter 618209 (2021-10-20)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/cellera-llc-618209-10202021)
5. [Q’Apel Medical, Inc. — Warning Letter 699244 (2025-02-05)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/qapel-medical-inc-699244-02052025)
6. [Mibo Medical Group — Warning Letter 558900 (2018-11-20)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/mibo-medical-group-558900-11202018)
7. [TELEMED — Warning Letter 540646 (2017-11-14)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/telemed-540646-11142017)
8. [NeuroSync, Inc. — Warning Letter 705489 (2025-05-09)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/neurosync-inc-705489-05092025)
9. [Beta Bionics, Inc. — Warning Letter 717927 (2026-01-28)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/beta-bionics-inc-717927-01282026)
10. [Nipro Renal Solutions USA, Corporation — Warning Letter 732874 (2026-07-24)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/nipro-renal-solutions-usa-corporation-732874-07242026)
11. [Medline Industries, LP — Warning Letter 677545 (2024-03-18)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/medline-industries-lp-677545-03182024)
12. [Jiangsu Shenli Medical Production Co., Ltd. — Warning Letter 687035 (2024-07-18)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/jiangsu-shenli-medical-production-co-ltd-687035-07182024)
13. [Micro-X Ltd. — Warning Letter 692084 (2024-09-10)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/micro-x-ltd-692084-09102024)
14. [Beckman Coulter Inc. — Warning Letter 678042 (2024-03-15)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/beckman-coulter-inc-678042-03152024)
15. [Lion Street Medical, d/b/a Pensar Medical LLC — Warning Letter 733015 (2026-08-21)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/lion-street-medical-dba-pensar-medical-llc-733015-08212026)
16. [ITL Asia Pacific Sdn Bhd — Warning Letter 590380 (2019-09-25)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/itl-asia-pacific-sdn-bhd-590380-09252019)
17. [Meridian Bioscience, Inc. — Warning Letter 720826 (2025-12-22)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/meridian-bioscience-inc-720826-12222025)
18. [Xoran Technologies, LLC — Warning Letter 694229 (2024-12-09)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/xoran-technologies-llc-694229-12092024)
19. [Primus Corporation dba Trinity Biotech — Warning Letter 607698 (2020-08-12)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/primus-corporation-dba-trinity-biotech-607698-08122020)
20. [Kabe Labortechnik GmbH — Warning Letter 704563 (2025-05-09)](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/kabe-labortechnik-gmbh-704563-05092025)