| Classes | IEC 62304:2006 Section | Document Section |
|---|---|---|
| A, B, C | 6.2.3 | 2 |
| A, B, C | 6.2.4 | 2 |
| A, B, C | 6.2.5 | 2 |
| A, B, C | 6.3.1 | 3 |
| A, B, C | 6.3.2 | 3 |
| A, B, C | 7.4.1 | 2 |
| B, C | 7.4.2 | 2 |
| B, C | 7.4.3 | 2 |
| A, B, C | 8.2.1 | 2 |
| A, B, C | 8.2.2 | 3 |
| A, B, C | 8.2.3 | 3 |
| A, B, C | 8.2.4 | 3 |
| A, B, C | 9.4 | (All) |
Overview
This Standard Operating Procedure (SOP) outlines how software changes are assessed and managed after release.
| Process Owner | \ |
| Key Performance Indicators | \ |
Key Considerations
Classification of Feedback
Feedback is categorized as either a bug fix or a standard change request:
- Bug fixes: These are minor changes made to the existing code and do not introduce new features or remove existing ones. They must not 1) lead to substantial changes to the medical device as defined by the change assessment criteria or 2) introduce new risks or failure modes.
- Standard Change Requests: Any change not classified as a bug fix.
Regulatory References
Change processing follows these regulatory guidelines:
- Medical Device Regulation, Annex IX Chapter II Section 4.10: “Any change to an approved device must be approved by the notified body responsible for the EU technical documentation assessment, especially if such changes could affect the device’s safety, performance, or intended use conditions. Manufacturers must notify the notified body of these changes, which will then assess if a new conformity evaluation is required or if the changes can be addressed through a supplement to the EU technical documentation assessment certificate. If approved, the notified body provides the manufacturer with the supplement to the certificate.”
- Medical Device Coordination Group (MDCG) Document 2020-03: “Guidance on significant changes related to the transitional provisions under Article 120 of the MDR for devices with certificates according to MDD or AIMDD.”
Process Overview
1. Initiation of a Change Request
Change requests can come from various sources, such as:
- Internal design initiatives
- Market analysis
- Customer feedback (refer to the feedback management process)
- Post-Market Surveillance (refer to the post-market surveillance process)
- Changes within the Quality Management System (QMS)
Proposals can be submitted by any member of the company.
The Product Manager documents the change proposal in the company’s project management tool, detailing the change.
| Participants |
|---|
| Any company member with a change proposal |
| Input | Output |
|---|---|
| Change proposal | Documented change request (ID assigned per product version) |
2. Change Evaluation
The Product Manager, along with the Regulatory Affairs Manager and the Head of Software Development, evaluates the proposed change. Initially, it is determined if the change is a bug fix or not. If it is a bug fix, the Product Manager includes it in the bug fix documentation list (link here).
If it is a regular change request, the evaluation includes assessing whether the change:
- Constitutes a significant modification (consult MDCG 2020-03 for guidance)
- Introduces any new risks and whether these risks are manageable
- Affects any current risk control measures
- Is feasible from a technical standpoint
- Aligns with the company’s product strategy
The results are documented in the Change Evaluation List and inform the decision on whether the change will be implemented and if the Notified Body’s involvement is required. The evaluation and decision are recorded in the change request ticket.
If necessary, the Notified Body is consulted before changes are executed. Multiple proposed changes can be assessed in a single session.
For changes involving parts of the QMS, an additional evaluation is conducted focusing on “organizational changes.”
| Participants |
|---|
| Product Manager |
| Head of Software Development |
| Regulatory Affairs Manager |
| Input | Output |
|---|---|
| Change request | Completed change evaluation |
3. Execution, Verification, Validation, and Documentation Updates
Approved change requests are fed into the SOP for Software Development and are implemented accordingly.
This phase includes verification, validation, and release processes, ensuring full traceability. Documentation is revised and released with an updated declaration of conformity.