WI-10 Risk

Work Instruction for Risk configuration items

1. Introduction

1.1. Purpose

This Work Instruction provides the tasks required to be performed as part of the Risk configuration item lifecycle.

1.2. Scope

This Work Instruction covers the complete Risk lifecycle, from creation to obsolescence.

1.3. Records and evidence

Records for each Risk will be held based on the records and retention policy. Risks are used to generate the following artifacts:

• Change management file

• Change request verification report

• Risk control matrix

• Risk management file

• Risk matrix

• System requirements specification (relations)

• System design specification (relations)

• System design specification (with details)

• Test plan (relations)

• Traceability matrix

1.4. Responsibilities

As listed in the procedure description, each task in the Risk 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 authoring and responsible for the Risk. This organization member is responsible for managing/completing the Risk lifecycle activities. This Item Assignee can change from time to time.

• Quality Managers: The person accountable for the Risk. The Quality Manager ensures the Risk is correctly documented.

• R&D Leads: The R&D Lead verifies the Risk is technically correct and any risk control measures are executable.

2. Procedure description

2.1. Step 1: Log into Ketryx

Anyone

1. Log into your Ketryx organization via app.ketryx.com and select the Ketryx project connected to the relevant Jira project.

2.2. Step 2: Create

Anyone

1. After product-level risk analysis is performed, for example, through a Failure Mode and Effects Analysis (FMEA), users should create a Risk to represent certain risks.

2. Navigate to the Risks page via the left-hand sidebar.

3. Press the Add risk button to open the form to create a new risk item.
4. Define an appropriate title in the Title field. To make the most out of Ketryx, it is recommended to name a Risk after its Hazardous Situation. Should there be multiple identical Hazardous Situations, one should differentiate each Risk item by including the hazard in the title. As an example:

   • Under Infusion (Electrical hazard) and

   • Under Infusion (Functional hazard)

5. Define the item metadata with an appropriate Assignee (the Item Assignee) and Introduced in version.

6. Press the Save changes button at the bottom of the page to finalize the creation of the new item.
7. After saving the item, you will be directed to the item details page, where information about the newly created item will be displayed.

2.3. Step 3: Change status to In Progress

Anyone

You can change the issue status to In Progress, either in Jira or Ketryx.

2.3.1. Transition in Ketryx

Transition an item on the All items page

1. Navigate to the All items page via the left-hand sidebar.

2. Select the item in question and transition it to In Progress using the Transition 1 item button.

Transition an item on the Edit risk page

1. Navigate to the Risks page via the left-hand sidebar.

2. For the relevant Risk item, click the Edit risk button.

3. Select In Progress in the State dropdown.

4. Save the changes.

2.3.2. Transition in Jira

1. Access the item in Jira via a link in Ketryx (e.g. in the item details page, risk management page or all items page). Then change the status using the issue status selector.

2.4. Step 4: Edit the Risk item in Ketryx

Item Assignee

1. Navigate to the Risks page via the left-hand sidebar.

2. For the relevant Risk item, click the Edit risk button.

2.5. Step 5: Add general Risk information

Item Assignee

As needed, fill in the relevant information in the Risk form:

1. Select one or more System categories.

2. Select one or more Risk assessment methodologies.

3. Fill in/select a Harm (based on the project configuration, a harm may prepopulate a pre-defined Initial severity value within the Initial risk analysis section)

4. Select a Hazard type (based on the project configuration, a hazard type may use a different risk analysis calculation schema).

5. Fill in the Hazardous situation.

6. Enter one or more steps for Foreseeable sequence of events leading to the hazardous situation (the Cause of the hazardous situation) by either selecting a pre-configured step, adding a new step, or loading a sequence of events.

2.6. Step 6: Perform an initial risk analysis

Item Assignee

1. Set the Initial likelihood of occurrence (P1).

2. Set the Initial likelihood of harm (P2).

3. Set the Initial severity (may be pre-selected depending on the Harm provided).

4. After P1, P2 and severity have been set, the Initial risk evaluation value will be set according to the project's configured risk evaluation matrix. You may override the value if necessary.

5. An information box is visible next to the Initial risk analysis section for improved comprehension of how the values were derived.

6. Verify the calculated value for Risk acceptability. If it is Acceptable go to Step 9, otherwise continue with Step 7 to identify potential risk controls.

2.7. Step 7: Add risk controls

Item Assignee

1. As needed, add some details in the Risk control description field.

2. Create risk control measure CIs as needed and add them under Risk control measures section by selecting the item in the corresponding dropdown and clicking the Add risk control measures button.

2.8. Step 8: Perform a residual risk analysis

Item Assignee

1. Set the Residual likelihood of occurrence (P1).

2. Set the Residual likelihood of harm (P2).

3. Set the Residual severity.

4. After P1, P2 and severity have been set, the Residual risk evaluation value will be set according to the project's configured risk evaluation matrix. You may override the value if necessary.

5. An information box is visible next to the Residual risk analysis section for improved comprehension of how the values were derived.

6. If the residual risk is still considered Not acceptable, perform a Benefit-risk analysis to ensure the benefit of the product justifies the unacceptable risk, or override the calculated acceptability by selecting Acceptable in the Overall risk analysis section.

7. If the calculated overall acceptability is overridden, this will be explicitly pointed out on the right-hand side.

8. Save the changes

2.9. Step 9: Change status to Resolved (Ready for Review)

Anyone

Once the Risk is completed and ready for design verification, it can be transitioned to Resolved in a similar way as described in 2.3. Step 3: Change status to In Progress. Please, note that Assignee needs to be set to be able to transition an item to Resolved.

2.10. Step 10: Review as Owner

Item Assignee

Review the Risk to verify:

• The Risk is traceable to all other needed items, and all interfaces are defined.

• The Risk is Specific, Measurable, Achievable, Relevant, and Testable (SMART).

• The Risk as a design output conforms to its design input (the items introducing the risk).

If the verification fails, provide a comment on the reason it failed if needed, then go to Step 4. If verification passes, approve the Risk either in Jira or in Ketryx as described in point 2.10.1. Risk approval.

2.10.1. Risk approval

Approval in Jira

1. Access the item in Jira via a link in Ketryx (e.g. in the item details page, risk management page or all items page).

2. Approve the item in the Approvals widget.

Approval in Ketryx

In Ketryx, risk items can be approved either on the All items page or on the Risk management page.

Approval on the All items page

1. Navigate to the All items page via the left-hand sidebar.

2. Select the item in question and approve it by clicking the Approve button.

Approval on the Risk management page

1. Navigate to the Risks page via the left-hand sidebar.

2. For the relevant item, click the Approve button.

2.11. Step 11: Review as R&D Lead

R&D Lead

Review the Risk to verify:

• The Risk is traceable to all other needed items, and all interfaces are defined.

• The Risk is Specific, Measurable, Achievable, Relevant, and Testable (SMART).

• The Risk as a design output conforms to its design input (the items introducing the risk).

If the verification fails, reopen the ticket and, if needed, provide a comment on the reason it failed, then go to Step 3. If verification passes, approve the Risk as seen in point 2.10.1. Risk approval.

2.12. Step 12: Review as Quality Manager

Quality Manager

Review the Risk to verify:

• The Risk is traceable to all other needed items, and all interfaces are defined.

• The Risk is Specific, Measurable, Achievable, Relevant, and Testable (SMART).

• The Risk as a design output conforms to its design input (the items introducing the risk).

If the verification fails, reopen the ticket and, if needed, provide a comment on the reason it failed, then go to Step 3. If verification passes, approve the Risk as seen in point 2.10.1. Risk approval.

2.13. Step 13: Transition to a controlled state

Ketryx

Only Ketryx can move a Risk to a controlled and effective state by transitioning its status to Closed. Ketryx moves the Risk to a Closed state after all approval rules have been passed, i.e., all required steps have approved the Risk.

Ketryx automatically adds a comment to the Jira issue with a link to the effective controlled record in Ketryx.

2.14. Step 14: Change

Item Assignee

Following a Change Request (i.e., the issue needs to be modified), reopen the Risk to create a new record, and go back to Step 3.

2.15. Step 15: Mark as obsolete

Item Assignee

To mark a Risk as obsolete (i.e., as not effective anymore, starting with a given version),

• Reopen it for change (Step 14),

• Set the version it will be obsolete in (i.e., where the first version that it will not be effective in anymore) in the Obsolete in version field,

• Resolve the issue (Step 9),

• Approve the item (Steps 10-12).

3. Procedure flow diagram

4. Item schema

• Introduced in version (version reference): The first version this risk is effective in. If empty, the risk is considered effective from the start of the project.

• Obsolete in version (version reference): The version the risk is becoming obsolete in, i.e., the first version that this risk is not effective anymore.

5. Traceability to other configuration items

The following relations can be defined from a Risk to other configuration items:

• Risk is risk-controlled by Test Case, Requirement, Software Item Spec, Hardware Item Spec

The following relations can be defined from other configuration items to a Risk:

• Risk is introduced by Requirement, Change Request, Hardware Item Spec, Software Item Spec

• Risk is affected by CAPA, Change Request, Anomaly

• Risk results from Change Request, CAPA