Overview

The Requirement Management Event within the ProcessX ALM Workflow is designed to capture both the GxP Assessment and Risk Assessment for each individual requirement that is not a parent. This document provides an overview of the out-of-the-box Risk Assessment Calculator for requirements.

Note: If you are a ProcessX client and are not utilizing USDM’s out-of-the-box Requirements Risk Assessment functionality within the ProcessX ALM workflow, please contact your ProcessX System Owner or USDM for guidance and reference to your specific Risk Assessment Help Guide.

DETERMINE GXP RELEVANCE FOR A REQUIREMENT

• The GxP Relevant option is displayed based on Requirement Type; where it is not applicable, it is not displayed.
  • Parent Requirements do not have the option to designate GxP Relevance; this is because Parent Requirements are used only to group related Child Requirements together and are not independently assessed.
  • Child Requirements (i.e., any Requirement Type other than ‘Parent’) display the GxP Relevant option, as this determination is mandatory for these Child Requirements.
• For Requirements that are GxP-relevant, select Yes from the GxP Relevant dropdown menu.
• For Requirements that are not GxP-relevant, select No or NA from the GxP Relevant dropdown menu.
• After determining GxP Relevance (i.e., selecting Yes, No, or NA), the Justification for GxP Selection field must be completed. This field is where you will document the rationale to explain your choice (e.g., why is this Requirement GxP Relevant or not?)

PERFORM GXP RISK ASSESSMENT FOR GXP RELEVANT REQUIREMENTS

• The GxP Risk tab within each Requirement captures the associated Risk Assessment and is mandatory when Requirements are identified as GxP Relevant.
• The GxP Risk tab includes the following sections:
  • Risk Rating and Categorization
  • Risk Classification and Priority Determination
  • Risk Mitigation
• For Requirements identified as non-GxP-Relevant, the GxP Risk fields are disabled (i.e., are read-only) and auto-populated as NA; this indicates Risk Assessment and Mitigation is not applicable.
• For Requirements identified as GxP Relevant, the GxP Risk fields are mandatory; you must complete the Risk Assessment for these Requirements. Refer to the pages below for information on each GxP Risk tab section.

RISK RATING AND CATEGORIZATION

• The Risk Rating and Categorization section captures the following:

• • Patient/Product Risk Impact: Select one of the following:
    • High: Direct impact on product quality.
    • Medium: Indirect impact on patient safety, with greater potential severity than that of Low Patient/Product Risk Impact.
    • Low: Indirect impact on patient safety, with minimal potential severity.
    • None: No potential impact on product quality or patient safety.
  • Software Category: Select one of the following:
    • Custom: Non-standard code or API involved in the Requirement.
    • Configured: Configuration elements are involved.
    • OOB: Standard, no customization or configuration required.

RISK CLASSIFICATION AND PRIORITY DETERMINATION

• The Risk Classification and Priority Determination section captures the following:
  • Risk Likelihood: This field is read-only and is automatically populated based on the selected Software Category:
    • Low if the Software Category is OOB.
    • Medium if the Software Category is Configured.
    • High if the Software Category is Custom.
  • Risk Classification: This field is read-only and is populated by the system, determined by both the Risk Likelihood and the Patient/Product Risk Impact. The Risk Classification is calculated using the following table:
    

    Patient/Product Risk Impact	Software Category	Risk Likelihood (from Software Category)	Risk Classification
    None	OOB	Low	1
    None	Configured	Medium	1
    None	Custom	High	1
    Low	OOB	Low	1
    Low	Configured	Medium	2
    Low	Custom	High	3
    Medium	OOB	Low	2
    Medium	Configured	Medium	3
    Medium	Custom	High	4
    High	OOB	Low	3
    High	Configured	Medium	4
    High	Custom	High	5

  • Probability of Detection: Select one of the following:
    • High: The product is 100% checked automatically, or there are at least two downstream automatic sample checks.
    • Medium: There is one automatic downstream sample check, or at least one procedural manual check.
    • Low: There are no automated downstream checks, and any manual checks are non-procedural.
      

      Risk Classification	Probability of Detection	Risk Priority
      1	High	Low
      2	High	Low
      3	High	Low
      4	High	Low
      5	High	Medium
      1	Medium	Low
      2	Medium	Low
      3	Medium	Low
      4	Medium	Medium
      5	Medium	High
      1	Low	Low
      2	Low	Low
      3	Low	Medium
      4	Low	High
      5	Low	High

The Risk Mitigation section reflects the planned actions to mitigate the risk associated with the requirement.

• • Planned Risk Mitigation: This field is read-only and is automatically populated by the system based on Risk Priority. The Planned Risk Mitigation is determined using the following table:The Risk Mitigation section reflects the planned actions to mitigate the risk associated with the requirement.
    • Planned Risk Mitigation: This field is read-only and is automatically populated by the system based on Risk Priority. The Planned Risk Mitigation is determined using the following table:
      

      Risk Priority	Planned Risk Mitigation
      Low	Refer to the SDLC testing performed by vendor or perform ad-hoc/unscripted testing. No further specific testing required
      Medium	Perform Acceptance Testing
      High	As is relevant per function – perform Challenge/Boundary/Stress testing as well as acceptance testing

    • Requires Scripted Testing: This checkbox is read-only and is populated by the system. It is automatically selected in the following scenarios:
      • When Planned Risk Mitigation is set to:
        • “Perform Acceptance Testing”
        • “As is relevant per function – perform Challenge/Boundary/Stress testing as well as acceptance testing.”
      • When Planned Risk Mitigation is “Refer to the SDLC testing performed by vendor or perform ad-hoc/unscripted testing. No further specific testing required,” and the Unscripted Testing, Reference Vendor documentation, or Scripted Testing? field is selected as ‘Scripted Testing’ by the user, the checkbox will also be selected.
    • NOTE: Requirements with the Requires Scripted Testing checkbox selected are reflected under the Scripted Test Creation task. These requirements must be associated with at least one scripted test when the corresponding task is routed and completed.
      • Unscripted Testing, Reference Vendor documentation, or Scripted Testing?: This field is only available when Planned Risk Mitigation is set to “Refer to the SDLC testing performed by vendor or perform ad-hoc/unscripted testing. No further specific testing required.” It allows the user to select one of the following options:
        • Unscripted Testing: This is selected when the requirement must be associated with an Unscripted Test in the subsequent Unscripted Test Execution task under the downstream ALM Test Execution Event of the ALM Project.
        • Reference Vendor Documentation: This is selected when the requirement does not need to be tested and relies on vendor documentation.
        • Scripted Testing: This is selected when the requirement must be associated with a Scripted Test in the subsequent Scripted Test Execution task under the downstream ALM Test Execution Event of the ALM Project.
      • Documentation Reference: This field is available when Unscripted Testing, Reference Vendor Documentation, or Scripted Testing? is selected as ‘Reference Vendor Documentation’. It allows the user to document any relevant vendor documentation information.