# Keeping impact assessments current with software releases

> Frequent software releases can outpace manual updates to design records, risk assessments, verification evidence, and regulatory documentation. Each change may affect previously accepted assumptions or risk controls. The challenge is to determine the regulatory and quality impact of each release consistently while maintaining traceability between the change, its assessment, the associated testing, and the approved product baseline.

- 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-15-impact-assessments-software-releases.md

15

**Category: CONTROL | Subcategory: Change**

Assessment area: Software Change Assessment

Frequent software releases can outpace manual updates to design records, risk assessments, verification evidence, and regulatory documentation. Each change may affect previously accepted assumptions or risk controls. The challenge is to determine the regulatory and quality impact of each release consistently while maintaining traceability between the change, its assessment, the associated testing, and the approved product baseline.

Software-based medical devices may change frequently through bug fixes, feature additions, dependencies, and platform updates. Regulatory and quality personnel must determine whether each change affects previously documented claims, requirements, hazards, controls, or verification evidence. When release activities move faster than document maintenance, assessment records can fall behind the product that is actually deployed.

A risk analysis that was appropriate for a prior release may no longer cover a modified workflow, new failure mode, or changed interface. Equally, it may be unnecessary to repeat the entire evaluation for every small change if the impact can be established and documented clearly. Teams need access to accurate change descriptions and a reliable way to trace affected records, rather than relying on recollection during a submission or audit.

The central challenge is to establish a sustainable, change-driven assessment process that keeps risk and regulatory evidence synchronized with software versions without slowing every release through indiscriminate reassessment.

---

## AskDona Assessment — Keeping Impact Assessments Current with Software Releases

**Topic ID:** 15  
**Status:** Current · verified 2026-10-15  
**Category:** CONTROL | **Subcategory:** Change  
**Assessment area:** Software Change Assessment  
**Scope:** Release-specific change impact, requirements–risk–test traceability, regression evidence, regulatory-impact review, and approved version baseline.

> **Interpretation and evidence note:** Section 1 contains the supplied challenge verbatim. Section 2 reproduces selected original wording from the **user-supplied FDA-related analytical text**, not direct quotations from FDA Warning Letters. These inspection examples are illustrative of documentation and control failures; they do not establish that any specific software release automatically requires a new 510(k). The cited FDA links are preserved as copyable full Markdown URLs. The AskDona proposals are evidence-review workflows, not autonomous safety or regulatory determinations. Product capabilities are separated into documented existing functionality, configuration-dependent workflows, and research/proposed integrations.

### 1. Original Challenge — Verbatim

#### Original summary

> Frequent software releases can outpace manual updates to design records, risk assessments, verification evidence, and regulatory documentation. Each change may affect previously accepted assumptions or risk controls. The challenge is to determine the regulatory and quality impact of each release consistently while maintaining traceability between the change, its assessment, the associated testing, and the approved product baseline.

#### Full original discussion

> Software-based medical devices may change frequently through bug fixes, feature additions, dependencies, and platform updates. Regulatory and quality personnel must determine whether each change affects previously documented claims, requirements, hazards, controls, or verification evidence. When release activities move faster than document maintenance, assessment records can fall behind the product that is actually deployed.
>
> A risk analysis that was appropriate for a prior release may no longer cover a modified workflow, new failure mode, or changed interface. Equally, it may be unnecessary to repeat the entire evaluation for every small change if the impact can be established and documented clearly. Teams need access to accurate change descriptions and a reliable way to trace affected records, rather than relying on recollection during a submission or audit.
>
> The central challenge is to establish a sustainable, change-driven assessment process that keeps risk and regulatory evidence synchronized with software versions without slowing every release through indiscriminate reassessment.

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

These excerpts are verbatim from the **supplied analytical narrative**; references in brackets retain its numbering. They are **not** claimed as quotations from FDA correspondence.

#### Insight 01 — Missing new-function risk traceability

> Adding new functions or requirements without updating your risk management files means critical hazards are left completely unmitigated.

#### Insight 02 — Regression gaps

> A central hazard of frequent software releases is "regression"—the risk that a change in one area will inadvertently disrupt unchanged portions of the codebase.

#### Insight 03 — Cybersecurity and platform changes

> Modern software releases often involve infrastructure changes, such as migrating from a desktop application to a web-based architecture [13].

**Fact check (16 Oct 2026, against the linked FDA pages):** **Supported.** O.N. Diagnostics [13] (VirtuOst VFA software): “the device has migrated from a desktop application to a web-based architecture”, raising network-exposed attack surfaces and authentication vulnerabilities; release 3.0.0 also added a machine-learning algorithm, which FDA treats as the more fundamental change.

#### Insight 04 — Regulatory filing assessment

> Frequent changes—even those intended as bug fixes or "device enhancements"—can cross the threshold of requiring a new premarket notification (510(k)) under 21 CFR 807.81(a)(3)(i) [6, 13, 17].

**Fact check (16 Oct 2026, against the linked FDA pages):** **Partly supported.** O.N. Diagnostics [13] and ICU Medical [17] (updated pump software disseminated after a Class I recall) both cite 21 CFR 807.81(a)(3)(i) for software changes requiring a new 510(k). Beta Bionics [6] **does not support** this: it has no 510(k) or 807.81 content; “device enhancement” was the **firm's** label, which FDA rejected in a correction-and-removal (21 CFR 806) context. “Frequent changes”, “bug fixes” and “device enhancements” are the analysis's framing, not FDA's wording.

#### Insight 05 — Version mismatch

> **Version Discrepancies:** Inspection findings often reveal discrepancies between the software version undergoing validation and the version actually released for mass production (e.g., validating version 2.1 but releasing version 2.5 without documenting the changes in between) [3].

**Fact check (16 Oct 2026, against the linked FDA pages):** **Supported, with a nuance.** Visgeneer [3] (eBchek glucose and uric-acid monitors): the validation report covers software version 2.1 while test reports and mass production reference 2.5, and the firm “did not describe any changes from the original software version”. The firm claimed 2.5 was also the initial production version; FDA's point is the unexplained version history.

#### Insight 06 — Outdated risk file

> **Acceptance of Outdated Risk Files:** During acquisitions or handoffs, firms sometimes accept outdated Risk Management Reports (e.g., a report from several years prior) that fail to assess cumulative post-production design changes and added hardware/device compatibility [9].

**Fact check (16 Oct 2026, against the linked FDA pages):** **Partly supported.** 3B Medical / Reach Health [9]: upon acquiring the iCodeConnect cloud software in May 2025, the firm “accepted an outdated version 1.1 of the Risk Management Report” dated 2016 (about nine years old) instead of version 4.0, which did not assess post-production design changes between 2018 and 2025, including added support for several ventilator devices. “Cumulative”, “hardware compatibility” and “handoff” are the analysis's words.

#### Insight 07 — Unsupported cosmetic decision

> **Informal "Cosmetic" Decisions:** A common pitfall is verbally communicating holds or informally dismissing code cleanups or minor updates as "cosmetic" or unrelated to safety without conducting a documented risk assessment tied to the device's design FMEA (dFMEA) [10].

**Fact check (16 Oct 2026, against the linked FDA pages):** **Partly supported; two findings merged.** Pensar [10]: the hold on ECO 25-033 “was communicated verbally only” (the firm's own memo), and a noise change was called “cosmetic in nature” without a documented risk assessment tied to the design FMEA. A separate ECO said to “clean up all code”, with no implementation or verification record and no one able to explain the code changes; that change was not the one called cosmetic. “Code cleanups” and “minor updates” are paraphrases.

#### Insight 08 — Inadequate testing scope

> **Over-Reliance on Black-Box Testing:** Validating software changes strictly at the system level using functional (black-box) testing, while omitting component and integration testing, fails to prove that the code changes were safely and completely implemented [11].

**Fact check (16 Oct 2026, against the linked FDA pages):** **Supported.** Xoran [11] (CT systems and software): software was “validated at the software system level, utilizing only functional testing (i.e., black-box) techniques” and “does not include component testing and integration testing”; the four test levels were defined in the **firm's own SOP**, and FDA also raised regression analysis.

#### Insight 09 — Release-specific change procedure

> Before any software change is implemented, a formal change control procedure must require a documented impact assessment [5, 7].

**Fact check (16 Oct 2026, against the linked FDA pages):** **Partly supported; not software-specific.** Sonesta [5] (radiographic and cystometric tables) lacked procedures for controlling changes, including determining impact on the design risk analysis and approving changes before implementation. Nipro [7] (hemodialysis concentrates; letter dated 16 July 2026) implemented packaging and specification changes without change records, risk analyses or documented impact assessments. Neither letter concerns software; software-specific support is in Xoran [11] and Pensar [10].

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

#### Finding 01 — New functions and risk controls can become disconnected

**(1) Original FDA-derived insight:** See the verbatim analytical excerpt in **Section 2, Insight 01**.

**(2) Regulatory / quality finding:** A new or modified function can reach production with no linked risk-analysis update or documented justification for non-applicability.

**(3) AskDona Assessment perspective:** Use release-specific, expert-authored criteria that check for links from changed software requirement IDs to relevant hazards, controls, and approved risk records. A missing link is a review trigger, not proof of an unmitigated hazard.

**(4) Proposed AskDona solution:** Import the release checklist from Excel; retrieve the change request, SRS, RMF/dFMEA and risk-control matrix from a scoped RAG repository; return preliminary status, explanation, exact quotation and source filename. Export gaps for RA/QA review.

**(5) Expected benefit:** Earlier detection of undocumented risk considerations; less manual requirements-to-risk evidence hunting.

**(6) Capability boundary:** Document checking is current; automatic creation/maintenance of a live traceability graph is proposed.

#### Finding 02 — Regression evidence can be missing or incomplete

**(1) Original FDA-derived insight:** See the verbatim analytical excerpt in **Section 2, Insight 02**.

**(2) Regulatory / quality finding:** Verification evidence may cover the modified function but not unaffected modules that could have been impacted indirectly.

**(3) AskDona Assessment perspective:** Ask whether documented regression scope and rationale address interfaces, affected unchanged functions and applicable unit/integration/system tests.

**(4) Proposed AskDona solution:** Assess release risk-impact records, test plans, regression matrices, results and deviations against explicitly defined coverage criteria; return Cannot determine when coverage cannot be verified from available evidence.

**(5) Expected benefit:** More explainable test-scope decisions and earlier exposure of testing-documentation gaps.

**(6) Capability boundary:** AskDona does not execute tests, compute code coverage or validate the adequacy of testing autonomously.

#### Finding 03 — Platform changes alter the risk and cyber context

**(1) Original FDA-derived insight:** See the verbatim analytical excerpt in **Section 2, Insight 03**.

**(2) Regulatory / quality finding:** Migration or new third-party dependencies may invalidate old architecture, authentication, connectivity and cybersecurity assumptions.

**(3) AskDona Assessment perspective:** Assess whether risk, cybersecurity and design records correspond to the release architecture and approved dependency set.

**(4) Proposed AskDona solution:** Scope the evidence corpus using device, release and platform metadata; cross-check architecture documents, software inventory/SBOM if supplied, cybersecurity reviews, risk assessments and verification reports.

**(5) Expected benefit:** Better visibility into unreviewed platform changes before release approval.

**(6) Capability boundary:** Live SBOM ingestion, vulnerability feeds, exploitability assessment and automated dependency impact tracing require additional integration and validation.

#### Finding 04 — Regulatory change classifications can be unsupported

**(1) Original FDA-derived insight:** See the verbatim analytical excerpt in **Section 2, Insight 04**.

**(2) Regulatory / quality finding:** An informal conclusion that no regulatory submission is needed may be unsupported by the documented nature and effects of change.

**(3) AskDona Assessment perspective:** Check the existence and completeness of a human-authored regulatory decision record: change description, affected intended use/performance, risk significance, applicable decision-tree rationale and approver.

**(4) Proposed AskDona solution:** Compare change records and submitted/cleared baseline documents with configured regulatory-assessment criteria and flag absent or contradictory support.

**(5) Expected benefit:** Better organized evidence for regulatory decision-makers and subsequent submission audits.

**(6) Capability boundary:** Only qualified RA personnel determine 510(k) applicability and filing strategy; no automatic trigger determination.

#### Finding 05 — Validated and deployed releases may diverge

**(1) Original FDA-derived insight:** See the verbatim analytical excerpt in **Section 2, Insight 05**.

**(2) Regulatory / quality finding:** Evidence created for one build may be relied on to approve a different deployed version.

**(3) AskDona Assessment perspective:** Treat release/build number, software configuration, test target and approved baseline as required evidence fields, not free-floating descriptive text.

**(4) Proposed AskDona solution:** Configure a checklist to compare release manifest, V&V report version identifiers, approval records and configuration records that have been provided.

**(5) Expected benefit:** Fewer silent version mismatches; clearer release evidence packages.

**(6) Capability boundary:** Current assessment can flag discrepancies in documents; direct CI/CD integration or cryptographically verified build attestation is not confirmed.

#### Finding 06 — Legacy risk analyses may not cover cumulative change

**(1) Original FDA-derived insight:** See the verbatim analytical excerpt in **Section 2, Insight 06**.

**(2) Regulatory / quality finding:** A signed older report may not reflect successive software, interface or hardware-compatibility changes.

**(3) AskDona Assessment perspective:** Assess whether the latest risk review explicitly evaluates all relevant releases since the last approved baseline and identifies changes that need reassessment.

**(4) Proposed AskDona solution:** Run criteria against the prior RMF, change history, compatibility records, current design specifications and review minutes; export uncovered intervals and assumptions.

**(5) Expected benefit:** Reduced reliance on retrospective reconstruction and more focused cumulative review.

**(6) Capability boundary:** Automated historical diffing and guaranteed full change-impact analysis remain proposed, not established production capabilities.

#### Finding 07 — Minor or cosmetic labels can mask safety significance

**(1) Original FDA-derived insight:** See the verbatim analytical excerpt in **Section 2, Insight 07**.

**(2) Regulatory / quality finding:** A change classification can substitute for a reasoned risk impact review.

**(3) AskDona Assessment perspective:** Evaluate the justification separately from the category name; demand evidence on changed behavior, interfaces, foreseeable harm and test impact.

**(4) Proposed AskDona solution:** Use calibrated labels such as Satisfied / Gap / Cannot determine; cite the ECO and risk evaluation; prompt a reviewer to inspect a missing dFMEA linkage or justification.

**(5) Expected benefit:** Consistent minimum evidence for streamlined minor-change decisions without forcing full reassessment every time.

**(6) Capability boundary:** AskDona cannot autonomously determine clinical safety or approve a no-impact classification.

#### Finding 08 — System-only testing can conceal coverage gaps

**(1) Original FDA-derived insight:** See the verbatim analytical excerpt in **Section 2, Insight 08**.

**(2) Regulatory / quality finding:** A documented release test may not establish the scope of low-level verification required by an expert-approved plan.

**(3) AskDona Assessment perspective:** Ask whether test depth and omissions are technically justified and aligned with the organization’s SOP and change risk.

**(4) Proposed AskDona solution:** Assess references between software-change assessment, unit/integration/system test reports, anomaly dispositions and documented waiver justifications.

**(5) Expected benefit:** Improved test-record completeness and review consistency.

**(6) Capability boundary:** Technical sufficiency and risk-based testing strategy require software/quality specialists.

#### Finding 09 — Change impact decisions lack structured ownership

**(1) Original FDA-derived insight:** See the verbatim analytical excerpt in **Section 2, Insight 09**.

**(2) Regulatory / quality finding:** Fast release cycles can skip cross-functional review or leave missing evidence unresolved.

**(3) AskDona Assessment perspective:** Apply one reusable release assessment schema with required assessment scope, supporting documents, decision owner and review status.

**(4) Proposed AskDona solution:** Execute Excel-imported assessment items for each release; use user input and metadata to select the relevant document set; export findings for controlled eQMS/ALM release approval.

**(5) Expected benefit:** More repeatable first-pass checks and fewer last-minute evidence collections.

**(6) Capability boundary:** Workflow routing, e-signature approval and automated sync to ALM/eQMS are not confirmed standard features.

### 4. Proposed Release-by-Release Assessment Model

1. **Identify the approved assessment baseline.** Capture device/product, software version/build, release date, intended use, approved requirements baseline, relevant design and risk revisions, and applicable market.
2. **Have experts configure change criteria.** Define rules for changed intended use/clinical performance, new functions, risk-control impacts, cybersecurity, dependencies, regression testing, regulatory assessment and outstanding anomalies. Applicability and acceptance criteria belong to the manufacturer’s qualified experts.
3. **Assemble controlled evidence.** Collect the change request/ECO, SRS, architecture, RMF/dFMEA, test plan and execution results, anomaly and complaint records, regulatory assessment and release approval. Tag files by release and revision before assessment.
4. **Run AskDona first-pass evidence checks.** Evaluate criteria independently against the selected RAG repository. Record preliminary label, reason, direct source quotation and source filename in an Excel output. **Cannot determine** means the supplied evidence is insufficient, not that the change automatically fails a regulation.
5. **Require human adjudication.** QA, software engineering, safety and regulatory reviewers verify sources and settle risk impacts, test extent, filing implications and release disposition. Enter the signed conclusion into the controlled system of record.
6. **Repeat for every applicable release.** Re-run the agreed checklist on a new controlled evidence set; make version and changes explicit. True automatic changes-only evaluation is an implementation/validation objective, not a promised built-in feature.

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

*The following are illustrative customer-configured checks, not a certified AskDona regulatory template.*

<div class="table-scroll">

| ID | Expert-defined first-pass criterion | Relevant documentary evidence | Example escalation trigger |
|---|---|---|---|
| SC-01 | Change identity, released build and prior approved baseline are identifiable. | Release manifest, change request, configuration record | Versions conflict or are missing |
| SC-02 | Modified/new requirements have a recorded safety-impact disposition. | SRS delta, dFMEA/RMF, risk matrix | No traceable disposition |
| SC-03 | Relevant risk controls are mapped to affected software requirements. | Risk control matrix, SRS, design specification | Link missing or obsolete |
| SC-04 | Intended-use, performance and clinical claims impact is addressed. | Change rationale, intended-use documentation, RA assessment | No rationale for no-impact claim |
| SC-05 | Interface and workflow changes have a use-related risk review as applicable. | UI spec, URRA/HF file, risk report | Changed user interaction unassessed |
| SC-06 | Regression scope considers affected unchanged components. | Regression analysis, test plan, test results | Unsupported exclusion of affected modules |
| SC-07 | Unit, integration and system evidence matches defined testing strategy. | Test strategy and reports | Missing required testing level or waiver |
| SC-08 | Cybersecurity and platform/dependency impacts are documented. | Architecture, SBOM, threat model, security V&V | Material change with no assessment |
| SC-09 | Remaining anomalies and deviations have reviewed dispositions. | Defect tracker export, deviation record, release review | Unresolved risk without authorized disposition |
| SC-10 | Regulatory change assessment and review authority are documented. | RA decision, cleared baseline, change history | Unsupported or unsigned decision |
| SC-11 | Actual tested configuration matches the intended released configuration. | Build identifiers, release record, V&V reports | Build/revision mismatch |
| SC-12 | Cumulative changes since prior risk review are considered. | Release history, latest RMF, compatibility records | Historical gap or stale risk document |

</div>

**Suggested preliminary label definitions:** `Satisfied` — evidence directly supports the defined criterion; `Gap` — supplied records show a clear inconsistency or omission under the criterion; `Cannot determine` — relevant records are unavailable or insufficient; `Not applicable` — only under explicitly configured applicability rules. An evidence gap does not by itself prove a regulatory violation.

### 6. Product Capability Boundary

<div class="table-scroll">

| Capability | Status based on supplied AskDona materials | Safe positioning |
|---|---|---|
| Import criteria from Excel and export item-level results | **Documented existing** | Repeatable release review checklists and exportable evidence reports |
| RAG retrieval and item-level result, explanation, quotation, source filename | **Documented existing** | Evidence-grounded first-pass document assessment |
| Pre-run questions, metadata filtering and item applicability filters | **Documented existing / configurable** | Release-specific review when documents are properly labeled |
| `Cannot determine` for insufficient documents | **Supported through configured assessment labels** | Avoid unsupported pass/fail decisions |
| Assessment copies/archives and historical runs | **Documented existing with lifecycle caveats** | Preserve separate assessment configurations for revision cycles; verify exact record retention rules |
| Integrated live SRS–risk–test graph, CI/CD trigger, automatic delta assessment | **Proposed / not confirmed as generally available** | Candidate integration with existing ALM/PLM/eQMS and validated data flows |
| Autonomous clinical risk, regression sufficiency or 510(k) determination | **Not established and not appropriate as final AI authority** | Expert decision is required |
| Exact end-to-end reproducibility | **Demonstrated in a constrained research pipeline, not universal commercial release behavior** | Validate repeatability separately for the intended deployment and evidence corpus |

</div>

AskDona's documented division of responsibility is **Criteria → Evidence retrieval → Preliminary assessment with citations → Human review and final decision**. In the supplied reproducibility study, a specially controlled research pipeline produced identical outputs in repeated tests with fixed configurations; this does **not** establish guaranteed production determinism, substantive assessment accuracy, or automatic release-impact coverage. The system of record should remain the manufacturer's validated QMS/ALM/PLM environment, rather than assuming AskDona supplies native approval, e-signature, or SDLC controls.

### 7. Suggested Pilot and Effect Measures

**Pilot design:** Select a device software product with a baseline release and approximately 3–5 later releases, covering a minor fix, interface change, dependency/platform update and higher-risk functional change. Have experts define expected assessment results independently. Upload version-controlled change records, requirements, risk files, V&V, cybersecurity and release records; deliberately include one inconsistent build ID and one missing regression rationale to test whether the system abstains/flags correctly.

<div class="table-scroll">

| KPI | Baseline / measurement method | Desired direction (not a claimed result) |
|---|---|---|
| Evidence review effort | Reviewer minutes per release and per criterion | Lower |
| Version mismatch detection | Recall of known release/build inconsistencies | Higher |
| Citation correctness | Expert-verified quotations and files / sampled citations | Higher |
| Impact rationale completeness | Assessed changes with an approved, supported rationale | Higher |
| Missing-evidence false assurance | Unsupported criteria incorrectly marked satisfied | Lower |
| Regression trace coverage | Changed requirements linked to relevant justified test scope | Higher |
| Review turnaround | Time from change package availability to documented expert disposition | Lower |
| Rerun stability | Agreement of label, file and cited passages on identical inputs | Higher |

</div>

**Adoption conditions:** Qualify and validate the tool for its defined intended use; establish access restrictions, source governance, prompt/checklist versioning, reviewer responsibility, record retention and change control; check exported quotes against the approved authoritative documents. Results and efficiencies must be established with local validation rather than extrapolated from other-industry proofs of concept.

### 8. FDA URLs — Copyable Markdown Links

The links below reproduce URLs included in the supplied analysis. They provide context for its regulatory examples; **the quoted words in this document come from the supplied analysis, not from a fresh verbatim transcription of those FDA pages**. FDA inspection guides are distinguished from Warning Letters.

- [1] [Royal Philips - 709948 - 09/09/2025 | FDA](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/royal-philips-709948-09092025)  
  `https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/royal-philips-709948-09092025`
- [2] [Adept Medical Ltd. - 692226 - 10/11/2024 | FDA](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/adept-medical-ltd-692226-10112024)  
  `https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/adept-medical-ltd-692226-10112024`
- [3] [Visgeneer, Inc - 709010 - 06/13/2025 | FDA](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/visgeneer-inc-709010-06132025)  
  `https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/visgeneer-inc-709010-06132025`
- [4] [Glossary of Computer System Software Development Terminology (8/95) | FDA](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/inspection-guides/glossary-computer-system-software-development-terminology-895)  
  `https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/inspection-guides/glossary-computer-system-software-development-terminology-895`
- [5] [Sonesta Medical AB - 667325 - 09/22/2023 | FDA](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/sonesta-medical-ab-667325-09222023)  
  `https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/sonesta-medical-ab-667325-09222023`
- [6] [Beta Bionics, Inc. - 717927 - 01/28/2026 | FDA](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/beta-bionics-inc-717927-01282026)  
  `https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/beta-bionics-inc-717927-01282026`
- [7] [Nipro Renal Solutions USA, Corporation - 732874 - 07/24/2026 | FDA](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/nipro-renal-solutions-usa-corporation-732874-07242026)  
  `https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/nipro-renal-solutions-usa-corporation-732874-07242026`
- [8] [Lex Inc. - 656056 - 08/17/2023 | FDA](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/lex-inc-656056-08172023)  
  `https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/lex-inc-656056-08172023`
- [9] [3B Medical, Inc. dba Reach Health, Inc. - 725108 - 05/20/2026 | FDA](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/3b-medical-inc-dba-reach-health-inc-725108-05202026)  
  `https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/3b-medical-inc-dba-reach-health-inc-725108-05202026`
- [10] [Lion Street Medical, d/b/a Pensar Medical LLC - 733015 - 08/21/2026 | FDA](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/lion-street-medical-dba-pensar-medical-llc-733015-08212026)  
  `https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/lion-street-medical-dba-pensar-medical-llc-733015-08212026`
- [11] [Xoran Technologies, LLC - 694229 - 12/09/2024 | FDA](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/xoran-technologies-llc-694229-12092024)  
  `https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/xoran-technologies-llc-694229-12092024`
- [12] [Computerized Systems in the Food Processing Industry | FDA](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/inspection-guides/computerized-systems-food-processing-industry-0)  
  `https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/inspection-guides/computerized-systems-food-processing-industry-0`
- [13] [O.N. Diagnostics, LLC - 730301 - 09/01/2026 | FDA](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/diagnostics-llc-730301-09012026)  
  `https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/diagnostics-llc-730301-09012026`
- [14] [Kabe Labortechnik GmbH - 704563 - 05/09/2025 | FDA](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/kabe-labortechnik-gmbh-704563-05092025)  
  `https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/kabe-labortechnik-gmbh-704563-05092025`
- [15] [Computerized Systems in Food Processing Industry | FDA](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/inspection-guides/computerized-systems-food-processing-industry)  
  `https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/inspection-guides/computerized-systems-food-processing-industry`
- [16] [Becton, Dickinson, and Company/CareFusion 303, Inc. - 691601 - 11/22/2024 | FDA](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/becton-dickinson-and-companycarefusion-303-inc-691601-11222024)  
  `https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/becton-dickinson-and-companycarefusion-303-inc-691601-11222024`
- [17] [ICU Medical - 702535 - 04/04/2025 | FDA](https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/icu-medical-702535-04042025)  
  `https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/warning-letters/icu-medical-702535-04042025`

**Fact check (16 Oct 2026, against the linked FDA pages):** all 17 linked pages were opened; firm names and letter numbers match, and each referenced insight carries a “Fact check” note. Nipro [7] is dated 16 July 2026 (24 July is the posting date). [15] is the same FDA food-industry inspection guide as [12] under a second URL. Among the uncited references, Adept Medical [2] concerns a modified device without software content and Lex [8] is a drug data-integrity letter; Philips [1], Kabe [14] (cumulative changes and a new 510(k)) and BD/CareFusion [16] (software updates not reported as corrections) are relevant to software or design changes.

### 9. Positioning Statement

**AskDona Assessment helps medical device teams keep software-release evaluations evidence-based and reviewable by checking expert-defined criteria against version-scoped change documents, risk records and verification results. It makes missing or conflicting justification visible earlier, while qualified software, quality and regulatory professionals retain responsibility for risk controls, validation scope, approval of the release and regulatory submission decisions.**