Sop change management
Company: Nikted
Document Name: Sop Change Management
Document Number: HAD-SOP-012
Author: Ghafar Nosrati
Date (Persian Calendar): 1404/06/31
Revision History
| Rev. no. | Description | Author(s) | Reviewers | Date (Persian) | Authors' Signature | Reviewers' Signature |
|---|---|---|---|---|---|---|
| 1. | Initial creation of Git Workflow | Ghafar Nosrati | Erfan Khebrati |
SOP Change Management
| Classes | IEC 62304:2006 Section | Document Section |
|---|---|---|
| A, B, C | 6.2.3 | 2.1 |
| A, B, C | 6.2.4 | 2.2 |
| A, B, C | 6.2.5 | 2.3 |
| A, B, C | 6.3.1 | 3.1 |
| A, B, C | 6.3.2 | 3.2 |
| A, B, C | 7.4.1 | 4.1 |
| B, C | 7.4.2 | 4.2 |
| B, C | 7.4.3 | 4.3 |
| A, B, C | 8.2.1 | 3 |
| A, B, C | 8.2.2 | 3.3 |
| A, B, C | 8.2.3 | 3.4 |
| A, B, C | 8.2.4 | 3.5 |
| A, B, C | 9.4 | (All) |
This table shows how each section of IEC 62304:2006 is addressed within this document.
The purpose of this mapping is to ensure regulatory compliance and to support audit and inspection readiness.
1. Purpose
The purpose of this document is to standardize processes for software development, change control, and code management within the Nikted software team.
These processes ensure that development activities are aligned with quality requirements and IEC 62304 compliance.
2. General Considerations
2.1 Project Hosting
All projects are hosted on the company’s GitLab instance at:
https://hamgit.ir/nikted-organization/hezbyte
2.2 Change Classification
- Bug Fixes: Minor code modifications that do not introduce new features or risks.
- Regular Changes: Major modifications that may introduce new risks, require evaluation of impact, or affect system behavior.
2.3 Responsibilities
- Developer: Create branches, write code and unit tests, open Merge Requests.
- Reviewer: Review changes, approve or request modifications.
- Product Manager / Team Lead: Ensure alignment of changes with product strategy and quality requirements.
2.4 Guidance Documents
The processing of changes is based on the following regulatory provisions and guidances:
-
Medical Device Regulation, Annex IX Chapter II Section 4.10: "Changes to the approved device shall require approval from the notified body which issued the EU technical documentation assessment certificate where such changes could affect the safety and performance of the device or the conditions prescribed for use of the device. Where the manufacturer plans to introduce any of the above-mentioned changes it shall inform the notified body which issued the EU technical documentation assessment certificate thereof. The notified body shall assess the planned changes and decide whether the planned changes require a new conformity assessment in accordance with Article 52 or whether they could be addressed by means of a supplement to the EU technical documentation assessment certificate. In the latter case, the notified body shall assess the changes, notify the manufacturer of its decision and, where the changes are approved, provide it with a supplement to the EU technical documentation assessment certificate."
-
Medical Device Coordination Group (MDCG) Document 2020-03: “Guidance on significant changes regarding the transitional provision under Article 120 of the MDR with regard to devices covered by certificates according to MDD or AIMDD”
3. Process Steps
3.1 Creation of Change Request
Change proposals can originate from various sources, e.g.: - Internal design ideas - Market research - Customer feedback (see process for feedback management) - Post-Market Surveillance (see process for post-market surveillance) - Changes to the QMS
They can originate from anywhere inside the company.
In Nikted, all change requests are managed through Jira: - The Product Manager (or request owner) creates a Change Request ticket in Jira. - Each change request is linked to the corresponding Epic and Version to maintain alignment with release planning and product strategy. - The ticket must include a clear description of the proposed change, rationale, and expected impact.
3.2 Branch Creation and Commit
- Identify the relevant task in Jira.
- Create a new branch named according to the task ID or using dash-case (e.g.,
HEZ-809-fix-bug). - Perform commits and pushes as required.
- Keep the branch updated with develop/main by performing Rebase instead of Merge to maintain a clean history.
3.3 Merge Request (MR)
- Create an MR with a clear and descriptive title.
- Assign appropriate reviewers.
- The author is responsible for:
- Writing Unit Tests
- Resolving Merge Conflicts
- Incorporating feedback
3.4 Code Review Process
Reviewers can:
- Approve and Merge the changes.
- Approve with comments, allowing the author to merge.
- Request modifications, where the author cannot merge until re-approved.
Team rule: All members must review their assigned MRs **first thing in the morning** to avoid delays.
3.5 Release and Documentation Update
- Once merged, changes are integrated into the main branch.
- Documentation must be updated and released along with the new version.
3.6 Traceability
To ensure traceability:
- Each branch must link to a Jira Task or ticket.
- Each MR must clearly describe the implemented changes.
- Significant changes must be documented and reported to Risk Management and the QMS.
4. Verification & Validation
4.1 Verification
- Unit Tests must be executed.
- Automated checks are performed by CI/CD pipelines.
4.2 Validation
- Approval by assigned reviewers.
- Pair programming or review sessions may be conducted when necessary.
4.3 Documentation Update
- Code changes must be reflected in design documents and release notes.
Note:
This document is developed in alignment with the requirements of IEC 62304 (software lifecycle for medical devices) and is part of the Nikted QMS.