"Pin-Compatible" Bluetooth Module: Design Change, Risk File, and Reflow Revalidation

"Pin-compatible" answers a mechanical question and none of the others.

Missing or insufficient:

• Design change control (ISO 13485:2016 7.3.9; 21 CFR 820.30(i)): changes must be reviewed, verified, validated as appropriate, and approved before implementation. The review must consider the effects of the change on constituent parts and product in use. A supplier change to a radio module is not a drop-in part: new firmware stack, new supplier's quality history, new failure modes, new cybersecurity surface.
• Risk management (ISO 14971, applied throughout per ISO 13485 7.1): the risk file is not updated. New hazards plausibly include loss of connectivity during data transfer, radio conformance/coexistence, firmware defects in a stack the firm did not write, supply-chain and end-of-life risk, and cybersecurity vulnerabilities in a third-party stack. "No impact on safety" is a conclusion that requires an updated risk analysis to support it - the conclusion cannot substitute for the analysis.
• Verification vs validation: functional and EMC testing are verification. Was software verification performed to the applicable software lifecycle standard (e.g., IEC 62304) for the firmware change? Was radio/wireless conformance re-tested? Was any use-environment validation done (pairing, range, data integrity under interference)? If the change touches data transmission used for clinical decisions, validation may be needed.
• Traceability of the assessment: who approved "no impact," on what evidence, and does the assessment document reference the specific analyses? An assessment that asserts a conclusion without an evidence trail is not a controlled review.
• Design outputs / DMR: the DMR was updated, which is correct - but the change record should show the corresponding updates to risk file, labelling/IFU if applicable, and regulatory filings. It shows none.

Reflow soldering is a special process - conformance cannot be fully verified by subsequent inspection and test of the product, so the process must be validated (ISO 13485:2016 7.5.6; 21 CFR 820.75).

Reasoning:

• The claim is circular. "Within the validated window" is only meaningful if the window was established for the equipment and configuration now in use. A new module changes the thermal mass and the component mix on the board; the prior validation may no longer bound the new configuration.
• Three profile runs are not a validation. A profile run demonstrates that the oven was at the setpoint on that occasion; it does not establish that the process consistently produces acceptable solder joints across the operating range, board population, and equipment condition. Expect IQ/OQ/PQ or a documented, justified equivalence rationale - and equivalence must be demonstrated with data (thermal profiles with thermocouples on the new module, plus solder-joint inspection, pull/shear testing, cross-sections, and any applicable IPC acceptance criteria).
• Revalidation triggers should be written into the process validation documentation: change in equipment, change in recipe/profile, change in materials or component mix, change in supplier of a critical component, adverse trend. If the CM's validation report does not define these triggers, that itself is a gap: the firm cannot show it evaluated this change against criteria, because none were written.
• Risk-based scoping: a high-volume, patient-safety-relevant solder joint (intermittent open circuit causing loss of readings) justifies a conservative approach. The correct outcome is either documented revalidation or a documented, evidence-based rationale that the change is within the validated envelope - one or the other, not an assertion.
• Who owns it: the legal manufacturer owns the CM's validation status, even if the CM performed the work. "The CM decided" is not an acceptable position for the manufacturer.

The auditor audits the firm's decision-making process and documentation, not the regulator's conclusion.

• What is auditable: did the firm perform and document a regulatory impact assessment against written criteria before implementation? Most QMS procedures define when a change is "significant" and require a documented determination. If the file contains only "pin compatible - no impact," the auditable nonconformity is the absence of a documented, justified regulatory assessment under the firm's own change-control procedure (and ISO 13485:2016 7.3.9, 4.2.4 for records). Audit that.
• What is not the auditor's call: whether a new 510(k) is legally required, or whether the notified body must approve the change before implementation. State the concern, cite the firm's obligation to notify the notified body of significant changes under its MDR conformity assessment arrangements, and ask the firm to demonstrate its determination and its evidence. If the determination is undocumented or appears inconsistent with its own criteria, that is the finding.
• Escalation is mandatory: this is a potential regulatory noncompliance affecting a product already shipped. Raise it during the audit to the person with authority (quality/regulatory leadership), record it in the closing meeting, and ensure the report states it plainly. An auditor who notes it quietly in a minor finding has failed the ethics dimension of the role.
• Grading: major. The change is significant by the firm's own subject matter (radio module plus firmware), product has shipped, and the assessment that should have caught it was not performed with evidence. The risk file gap and the revalidation gap are separate findings with separate owners.
• Report language: condition, criterion, evidence, and the specific question the firm must answer - not a legal opinion. "The change assessment contains no documented evaluation of the new failure modes or of regulatory notification requirements; the risk management file was not updated; product has shipped." That is defensible, factual, and leaves the regulatory determination where it belongs, while making it impossible to ignore.