Engineering Change Request (ECR) is a formal, documented proposal to modify a released medical device, component, process, or specification. It records the problem, the proposed change, and the reason, then triggers an impact assessment and approval workflow before any change is authorized, verified, validated where needed, and implemented under change control.
What is an Engineering Change Request (ECR)?
An Engineering Change Request (ECR) is the starting point of formal change management. A team raises one when something about a released design needs to change: a part that fails in the field, a discontinued component, a usability issue found after launch, or a specification correction. The ECR describes the issue and proposes a fix, but does not authorize anything on its own.
Once raised, an ECR moves into review. If approved, it is converted into an Engineering Change Order (ECO), also called an Engineering Change Notice (ECN), which directs exactly how drawings, the bill of materials, work instructions, and the device master record are updated. In a medical device setting, the ECR sits inside the design and development change process defined by ISO 13485.
Why does an Engineering Change Request (ECR) matter in medical device development
A change to a regulated device can ripple into patient safety, regulatory status, and supply continuity. An uncontrolled change that skips review is one of the most common and most serious audit findings. If a part substitution alters biocompatibility, or a software fix changes how an alarm behaves, the effect reaches the risk file, verification evidence, and labeling.
The ECR forces those questions before the change ships. It creates the traceable record auditors and notified bodies expect: what changed, why, who assessed the impact, and what testing confirmed it was safe. Skip the step and you risk a nonconforming product, recalls, or a significant change in shipping without the required notification.
How the Engineering Change Request (ECR) process works
Engineering change management follows a defined sequence. Gates vary by company, but the core steps are consistent:
- Raise the request. Someone documents the problem, the affected items, the proposed change, and the justification.
- Assess impact. A cross-functional review evaluates the effect on design inputs and outputs, the risk management file (ISO 14971), verification and validation, labeling, and manufacturing.
- Classify the change. The team decides whether it is minor or significant, and whether it needs notified body notification under EU MDR 2017/745 or a new 510(k) in the United States.
- Approve or reject. Authorized reviewers sign off. Approval converts the ECR into an ECO.
- Implement and verify. Documents, tooling, and production records are updated, and any required verification or validation is completed before release.
Clause 7.3.9 of ISO 13485 requires that design and development changes be reviewed, verified, validated where appropriate, and approved before implementation. Since the FDA QMSR took effect in February 2026, 21 CFR Part 820 incorporates ISO 13485 by reference, so this discipline now anchors US compliance too. For software, IEC 62304 adds change and problem-resolution requirements.
Common challenges and best practices
The most frequent failure is treating an ECR as paperwork rather than a risk decision. Teams approve a change quickly to keep a line running, then find the risk file and verification evidence were never updated. Another common gap is a missing significant-change assessment.
Good change control keeps a few habits. Route every request through an explicit impact assessment that names the affected design outputs and risk controls. Make the significant-change determination a required, recorded step. Keep the ECR and its resulting ECO linked so traceability holds during an audit. Where a change touches software, tie it back to IEC 62304 configuration and problem-resolution records, and split unrelated changes into separate requests.
How SJML helps with Engineering Change Request (ECR)
SJML manages engineering changes as part of its design, manufacturing, and regulatory services for medical devices. Its teams run phase-gate programs with built-in change control, assessing each proposed change against design inputs, risk management files, and verification evidence. For products already on the market, SJML’s sustaining engineering and regulatory sustenance services handle change governance, value engineering, and obsolescence-driven changes while minimizing revalidation and rework. Quality and regulatory specialists assess whether a change is significant enough to need a notified body or FDA notification, so decisions are recorded rather than missed.
Talk to SJML’s engineering team →
Frequently asked questions
An Engineering Change Request (ECR) is the proposal stage. It captures the problem and the suggested change for review. An Engineering Change Order (ECO), sometimes called an Engineering Change Notice (ECN), is the approved instruction that authorizes the change and directs how to update documents, drawings, and production. The ECR comes first; the ECO implements what the ECR requested.
ISO 13485:2016 clause 7.3.9 governs control of design and development changes. It requires each change to be identified, reviewed, verified, validated where appropriate, and approved before implementation. Since February 2026, the FDA QMSR (21 CFR Part 820) incorporates ISO 13485 by reference, so the same change-control discipline now applies to devices marketed in the United States.
No. Only significant changes require notification. Under EU MDR 2017/745, changes to design or intended purpose can trigger a new conformity assessment or notified body review. For US devices, a change that affects safety or effectiveness may require a new 510(k). Run a documented significant-change assessment on every ECR so notification decisions are deliberate and recorded.
A complete ECR states the affected item or document, the current condition, the proposed change, and the reason for it. It should reference impacted design outputs, the risk management file, and any verification or validation the change affects. Strong requests also note cost, schedule, and inventory impact so reviewers can prioritize and approve with full context.
Related terms
- Engineering Change Order (ECO)
- Design Controls
- Risk Management File (ISO 14971)
- Design Verification
- Configuration Management
