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

1. Approvals widget: A dedicated Jira ticket section showing the current approval state within Ketryx.

2. CAPA: Corrective and Preventive Actions

3. RCI: Root Cause Investigation

4. RCA: Root Cause Analysis

5. 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 groups. When any of these approval group 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

1. In Jira, select Create
2. Make sure the issue type is Anomaly.
3. 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

1. Select the Status button and click Start Progress.

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

1. Following the RCI, plan the scope of the needed change, trace and document affected items.

2. If not defined already, set the Introduced in version field to the first version known to be affected by the Anomaly.

3. 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.

4. 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.

1. Use the issue status button to select Ready for Review.

2.10. Step 10: Review as Owner

Item Assignee

1. 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.

2. Find the Approvals widget.

3. Press Approve.

2.11. Step 11: Review as R&D Lead

R&D Lead

1. 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.

2. Find the Approvals widget.

3. Press Approve.

2.12. Step 12: Review as Quality Manager

Quality Manager

1. 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.

2. Find the Traceability widget.

3. Ensure the Traceability widget shows a related Test Case that tests for this Anomaly.

4. Find the Approvals widget.

5. Press Approve.

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 groups 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:

1. Select the status button.

2. Press Reopen.

3. Go back to Step 3.

2.15. Step 15: Re-assessing deferred Anomalies

R&D Lead

Deferred Anomalies should be re-assessed regularly:

1. In Jira, find all Anomaly tickets with the status Open and a non-empty Rationale for deferring resolution.

2. Check each item or notify the responsible person to ensure the rationale remains valid.

3. In case of an out-of-date rationale, update the content accordingly.

4. 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