SOP Change Management
|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|
|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)|
This SOP describes how we evaluate and make changes to our software after it’s released.
1. Creation of Change Request
Changes proposals can originate from various sources, e.g.:
- Customer feedback
- Market research
- Internal ideas
They can originate from anywhere inside the company.
A change request is created with a description of the proposed change.
|Anyone in the company with a change proposal|
|Change proposal||Change request|
2. Evaluation of Change
The proposed change is evaluated. Most importantly, it is evaluated whether the change:
- Is a substantial change (refer to e.g. MDCG 2020-03 for guidance)
- Introduces any new risks and whether those are acceptable
- Impacts any existing risk control measures
- Is technically feasible
- Makes sense for the product strategy of the company
The evaluation results in a decision whether the change is implemented and whether the notified body needs to be involved if the change is substantial. These two decisions are documented in the change request.
Multiple proposed changes can be batched and discussed in one session.
|Head of Software Development|
|Change request||Change request (updated)|
3. Implementation, Verification, Validation, Update of Documentation
The change results as input to the SOP Software Development and is implemented accordingly.
This includes verification, validation and release activities while ensuring traceability. The relevant documentation is updated.
Template Copyright openregulatory.com. See template license.
Please don’t remove this notice even if you’ve modified contents of this template.