Sop software problem resolution
Company: Nikted
Document Name: SOP software problem resolution
Document Number: HAD-SOP-014
Author: Ghafar Nosrati
Date (Persian Calendar): 1404/06/30
Revision History
| Rev. no. | Description | Author(s) | Reviewers | Date (Persian) | Author Signature | Reviewer Signature | Approver |
|---|---|---|---|---|---|---|---|
| 1 | Initial version | Ghafar Nosrati | Erfan khebrati | 1404/06/30 |
SOP Software Problem Resolution
| Classes | IEC 62304:2006 Section | Document Section |
|---|---|---|
| B, C | 5.6.8 | (All) |
| A, B, C | 6.2.1.3 | 1 |
| A, B, C | 6.2.2 | (All) |
| A, B, C | 9.1 | 1 |
| A, B, C | 9.2 | 2 |
| A, B, C | 9.3 | 3 |
| A, B, C | 9.5 | 1 |
| A, B, C | 9.6 | 2 |
| A, B, C | 9.7 | 3 |
Summary
This document describes the bug management and resolution process at Nikted, implemented in compliance with IEC 62304, Chapter 9 (Software Problem Resolution Process).
The process ensures that all bugs are systematically reported, analyzed, resolved, tested, and documented, and that their links to requirements, risks, and released software versions are fully traceable.
1. New Problem Evaluation
All bugs are created in a dedicated Jira project called SoftWare-BUG (62304) (key = SBUG). Mandatory fields include Bug Description, Occurrence Date, Application, and Application Version.
Reported problems can originate from customers, users or company employees. Examples include customer feedback and bug reports.
For each problem report, the following must be entered:
- Affected medical device and version
- Severity classification (see below)
- Problem description incl. instructions to reproduce
We classify the severity of problems in the following categories:
| Severity Classification | Description |
|---|---|
| High | Causes new or changed risks to patients which are unacceptable. |
| Medium | May cause new or changed risks to patients which are acceptable. |
| Low | All other problems. |
For all problems classified as "Medium" or higher the person responsible for regulatory compliance ( PRRC) must be informed who subsequently assesses it according to the SOP Vigilance.
| Participants |
|---|
| Head of product development |
| Person responsible for regulatory compliance |
| Input | Output |
|---|---|
| New problem | Problem report as jira tickets |
2. Root Cause Analysis and Procedure
The root cause of the problem is determined (if possible) and a decision is made whether to fix it or not.
We also analyze whether similar problems have occurred in the past and any trends can be discerned. If this is the case, it is noted in the problem report.
| Participants |
|---|
| Head of software development |
| Software developer |
| Input | Output |
|---|---|
| Problem report | Problem report updated with cause and procedure |
3. Implementation and Verification
Resolution
- The bug fix is implemented. If the fix includes a change to an existing product, it is handled according to SOP Change Management.
- The bug fix is documented in Jira.
- QA documents the Preventive Action (new test cases, process improvements).
- Bugs are linked to implementation tickets (e.g., GitHub/GitLab Pull Requests).
Verification & Testing
- QA executes related test cases, documenting the results, the tester, and the completion date.
- Automated CI/CD pipelines may also run to ensure regression coverage.
Closure & Release
- After the bug fix has been implemented, the problem report is reviewed whether it has been successfully fixed and can be closed. Closing the problem report is equivalent to successful verification.
- The Release Date is recorded once the corrected software version is deployed.
| Participants |
|---|
| Head of product development |
| Person responsible for regulatory compliance |
| Input | Output |
|---|---|
| Problem report | Resolved/closed problem report |
| Implemented change |
Jira
For managing bugs, we use the Jira system.
The setup is based on two separate but interconnected projects:
- Development Project (Dev): The main project where development tasks and sprints are managed.
- Bug Project (SBUG): A dedicated project where all bugs are reported, documented, and tested.
A bridge between the Bug Project and the Dev Project was implemented:
- Bugs are first created and tested in the SBUG project.
- Through workflows and automation, validated bugs are automatically linked to the Dev Project.
- The development team reviews these bugs and, based on risk level and severity, decides which ones are pulled into the Sprint Review for prioritization and resolution.
This setup ensures:
- Clear separation between development tasks and bug tracking.
- Full visibility of bugs within the Dev project workflow.
- Regulatory compliance by keeping test documentation and assessments in the Bug Project while ensuring fixes are implemented in Dev.
🔗 **Jira Project Link: ** Nikted Jira – Bug Project
Main Fields in Jira
see here
Compliance with IEC 62304
- Traceability: Each bug is linked to requirements, risks, implementation tickets, and test evidence.
- Accountability: Roles (Author, Reviewer, Approver) are explicitly recorded in Jira fields.
- Repeatability: Preventive Actions are logged to reduce the likelihood of recurrence.
- Audit Readiness: Jira reports and exports provide structured, verifiable records for audits.
Benefits of This Implementation
- Establishes a centralized and auditable system for bug management.
- Prevents uncontrolled fixes by enforcing structured approvals.
- Improves communication between QA and the development team through cross-project linking.
- Reduces the risk of non-compliance with IEC 62304.
- Provides a live end-to-end traceability chain from Bug → Requirement → Risk → Fix → Test → Release.
Jira Word Export
Exporting Multiple Issues to Word
- Go to Issues → Search for issues.
- Apply your desired filter or JQL (e.g., all bugs from project SBUG).
- From the top-right, click Export.
- Choose Export to Word (All fields) or Export to Word (Current fields).
- A Word file containing all listed issues will be downloaded.
Note: If you don’t see the Word option, your Jira admin may have disabled Word Exporter. In that case, export to HTML or CSV and then open/convert it in Word.
Sample Bug Report
[SBUG-19] Client app can not perform scan in some devices
| Field | Value |
|---|---|
| Status | To Do |
| Created | 21/Sep/25 |
| Updated | 21/Sep/25 |
| Project | SoftWare-BUG (62304) |
| Type | Bug |
| Priority | High |
| Reporter | Ghafar Nosrati |
| Assignee | Unassigned |
| Environment | POCO m5s with Android version 13 and MIUI version 14 |
| Affected Risk | Hazardous Situation ID: 9.2 in HAD_DOC-026 |
| Affected Software Requirement | SR-01 until SR-09 |
| Author | Mohammad Erfan Khebrati |
| Application | Niktone Client |
| Application Version | V1.4.1 |
| Description | The client app does not find nearby devices |
| Corrective Action | Update bluetooth 3rd party library to version 3.9.0 |
| Preventive Action | Refactor all document version strings in a global .libs file thus easier tracking |
| Preventive Action | Refactor all document version strings in a global .libs file thus easier tracking |
| Test Documentation | A unit test is added that ensures bluetooth scan functionality works properly in android version 14 |
| Test Completed Date | 23/Sep/25 |
| Test Person | Erfan Khebrati |