WI-06 Anomaly
Work Instruction for Anomaly configuration items
1. Introduction
1.1. Purpose
This Work Instruction provides the set of tasks required to be performed as part of the Anomaly configuration item lifecycle.
1.2. Scope
This Work Instruction covers the complete Anomaly lifecycle. Records for each Anomaly will be held based on the records and retention policy.
1.3. Records and evidence
Records for each Anomaly will be held based on the records and retention policy. Anomalies are used to generate the following artifacts:
Change management file
Change request verification report
Testing report (Found anomalies)
Test Plan (Tested items)
Unresolved Anomalies (with details)
1.4. Definitions and Acronyms
Approvals widget: A dedicated Jira ticket section showing the current approval state within Ketryx.
CAPA: Corrective and Preventive Actions
RCI: Root Cause Investigation
RCA: Root Cause Analysis
Traceability widget: A dedicated Jira ticket section showing the item relations within Ketryx
1.5. Responsibilities
As listed in 2.1 in the procedure description, each task in the Anomaly item’s lifecycle will be completed by a member that is part of one of the following approval steps. When any of these members can perform the task, Anyone is listed.
Item Assignee: The person responsible for the Anomaly. This organization member is responsible for managing/completing the Anomaly lifecycle activities. This Item Assignee can change from time to time.
Quality Manager: The person that verifies the Anomaly is correctly documented, investigated, and completely tested. The Quality Manager is consulted to approve the Anomaly.
R&D Lead: The person that is accountable for the Anomaly. The R&D Lead is consulted to investigate, resolve, and approve the fix for the Anomaly.
2. Procedure description
2.1. Step 1: Log into Jira
Anyone
Log into your Jira organization, e.g., your-company.atlassian.net.
2.2. Step 2: Create
Anyone
Draft the template, adding information as needed. The only required field is the Summary, marked by a red asterisk (*).
2.3. Step 3: Navigate to the issue page
Anyone
Using the popover shown by Jira or through other means, navigate to the Jira page of the Anomaly.
2.4. Step 4: Change status to In Progress
Anyone
2.5. Step 5: Perform Root Cause Analysis
Item Assignee
Perform a Root Cause Investigation (RCI) to discover the root cause of the Anomaly and put the findings in the Root cause analysis field. Incorporate other team members as required.
2.6. Step 6: Trace, plan and refer to affected items and version
Item Assignee
Following the RCI, plan the scope of the needed change, trace and document affected items.
If not defined already, set the Introduced in version field to the first version known to be affected by the Anomaly.
Plan what actions need to be taken, and based on the scope and impact of the change, issue CAPA(s) or Change Request(s) and connect to the Anomaly.
Either proceed with Step 6 if the anomaly should be deferred; otherwise, introduce the necessary changes in Step 7.
2.7. Step 7: Mark as deferred
Item Assignee
If the Anomaly is not fixed in the upcoming version (i.e., there is no Obsolete in version set), document the reason using the Rationale for deferring resolution field.
2.8. Step 8: Address changes
Item Assignee
Introduce the necessary changes according to the plan.
2.9. Step 9: Change status to Resolved
Item Assignee
Once the Anomaly is completely fixed (i.e., all necessary changes are implemented), set the Obsolete in version field to the upcoming version where the fix will be deployed.
2.10. Step 10: Review as Owner
Item Assignee
Read through the Anomaly and verify the RCI was performed correctly, that it is completely fixed by the suggested changes, and that those changes are implemented.
Find the Approvals widget.
2.11. Step 11: Review as R&D Lead
R&D Lead
Read through the Anomaly, review whether the RCI was performed correctly, that it is completely fixed by the suggested changes, and that those changes are implemented.
Find the Approvals widget.
2.12. Step 12: Review as Quality Manager
Quality Manager
Read through the Anomaly, review whether the RCI was performed correctly, that it is completely fixed by the suggested changes, and that those changes are implemented.
Find the Traceability widget.
Ensure the Traceability widget shows a related Test Case that tests for this Anomaly.
Find the Approvals widget.
2.13. Step 13: Transition to a controlled state
Ketryx
Only Ketryx can move an Anomaly to a controlled and effective state by transitioning its status to Closed. Ketryx moves the Anomaly to a Closed state after all approval rules have been passed, i.e., all required steps have approved the Anomaly.
Ketryx automatically adds a comment to the Jira issue with a link to the effective controlled record in Ketryx.
2.14. Step 14: Change status to Reopened
Anyone
If an Anomaly needs to be reopened:
Select the status button.
Press Reopen.
Go back to Step 3.
2.15. Step 15: Re-assessing deferred Anomalies
R&D Lead
Deferred Anomalies should be re-assessed regularly:
In Jira, find all Anomaly tickets with the status Open and a non-empty Rationale for deferring resolution.
Check each item or notify the responsible person to ensure the rationale remains valid.
In case of an out-of-date rationale, update the content accordingly.
In case the Anomaly shouldn’t be deferred any longer, clear the contents of the Rationale for deferring resolution field. Go back to Step 3.
3. Procedure flow diagram
4. Item schema
Description (rich text): A detailed description of the Anomaly.
Environment (short text): E.g., Home vs. Hospital
Problem Report Type: The type of problem report (often related to the resulting action or change needed).
Safety
Security
Performance
Human factors
Mechanical
Bio-medical
Chemical
Impact Scope: Informed by, e.g., size of the change, number of device models affected, supported accessories affected, resources involved, and time to change.
Small
Medium
Large
Impact criticality: How critical this anomaly is to the system.
Low
Medium
High
Impact on system (rich text): The impact this issue could have on the system.
Root Cause Analysis (rich text): Description of the root cause following an investigation.
Rationale for deferring resolution (rich text): A detailed description explaining the rationale for deferring the solution for an Anomaly. An Anomaly will be considered a Deferred Anomaly as long as the description is set.
Affected items (-> Requirement, Software Item Spec, Hardware Item Spec, Test Case, Risk, Configuration Item, CAPA, Anomaly, Change Request): Items affected by this change or issue.
Resolved by (-> Requirement, Software Item Spec, Hardware Item Spec, CAPA, Change Request)
Related issues (-> Anomaly)
Introduced in version: Version in which the Anomaly was first detected.
Obsolete in version: Version in which the Anomaly is fixed.
Priority
Low
Medium
High
5. Traceability to other configuration items
The following relations can be defined from an Anomaly to other configuration items:
Anomaly is resolved by Hardware Item Spec, Requirement, Change Request
Anomaly relates to Anomaly
Anomaly affects CAPA, Change Request, Anomaly, Configuration Item, Risks, Hardware Item Spec, Requirement, Software Item Spec
The following relations can be defined from other configuration items to an Anomaly:
Anomaly is implemented by Task
Anomaly was found by Test Execution
Anomaly results from Change Request, CAPA
Anomaly is affected by CAPA, Change Request, Anomaly
Anomaly related to Anomaly, Complaint
Last updated
