# System Suitability Testing System Suitability Testing is used in pharmaceutical labs to ensure that the lab's systems (such as chromatography systems and spectrophotometers) are functioning properly and providing reliable results. This is done by performing measurements on Quality Control (QC) samples: blanks (water) or reference standards. The QC samples must pass predefined acceptance criteria in order for the system to be considered suitable for use. Veeva LIMS leverages *Test Definition Variations* to allow Lab Analysts to easily perform System Suitability Testing alongside our standard *Test Execution* process. This feature must be configured by an Admin before it can be used. ## Design Data Admin Steps In order for Lab Analysts to be able to create QC samples and complete System Suitability Testing, a Design Data Admin must first set up a *Test Definition Variation* for each *Test Definition* that requires System Suitability Testing. In addition to the standard *Test Definition Variation* setup steps, the Design Data Admin should ensure the following: 1. The *Test Definition Variation* has the correct value selected in the **Quality Control Sample Type** field. The default values available are *Blank* and *Reference Standard*, but a Vault Admin can also configure custom values. 2. The *Test Definition Criteria* is defined. ## About Test Definition Criteria *Test Definition Criteria* is a child object of *Test Definition* that tracks the criteria that *Quality Control Samples* should be tested against. Conceptually, *Test Definition Criteria* is the same as *Spec Data Criteria*, except that it is associated with a *Test Definition* instead of *Spec Data*. Because *Quality Control Samples* are created ad hoc and therefore are not associated with any *Spec Data*, they require a different solution to define their criteria.

Note: Test Definition Criteria uses the same Criteria Evaluation object as Spec Data Criteria. The Criteria Evaluation*_ object has reference fields for both, but only one should be used at a time. If a given _Criteria Evaluation record has both of those fields populated, an error will occur.

### Creating Test Definition Criteria Before creating *Test Definition Criteria*, you must set up a *Test Definition Variation* with the required *Quality Control Sample Type*. To create *Test Definition Criteria*: 1. Navigate to the *Test Definition* for which you've created your *Test Definition Variation*. 2. Expand the **Test Definition Criteria** section and click **Create**. 3. Select **Quality Control Sample Criteria**. 4. Click **Continue**. 5. Select the **Test Definition Variation** you created. 6. Select a **Result to Evaluate**. 7. Select a **Variation Result to Evaluate**. 8. Select an **Indication**. This determines how the *Test Definition Criteria* is represented during *Test Execution* (if applicable) and whether failing this criteria prevents spec conformance. 9. Enter a **Criteria** formula. 10. Enter a **Criteria Description**. This functions as a more human-readable representation of the *Criteria* formula. 11. Click **Save**. ## Performing System Suitability Testing When configured by an Admin, Lab Analysts can create *Quality Control Samples* as needed from the *Edit Test Set* dialog in the Test Execution UI. To do so, complete the following steps: 1. In the *Edit Test Set* dialog, hover your mouse directly below the list of currently included samples and click the **+ Quality Control Sample Type** button that appears. 2. Select a **Sample Type** in the drop-down menu that appears. 3. Optional: Edit the auto-populated **Name**. 4. Select a **Variation**. 5. Click **Save**.

Once the Lab Analyst saves a *Quality Control Sample*, Veeva LIMS checks for an existing *Quality Control Spec Execution* for the current *Test Set* and, if one does not already exist, creates one automatically. After that, the system creates a new *Lab Test* associated with the *Spec Execution* for each newly created *Quality Control Sample*. These *Lab Tests* are all based on the selected *Lab Test Definition Variation*. Next, the system creates any necessary child objects for the *Lab Tests*, such as *Test Steps*, *Test Results*, *Test Inputs*, *Test Result Variables*, and *Criteria Evaluations*. ### Flow When a Quality Control Sample Does Not Meet its Criteria When a *Quality Control Sample* does not meet its criteria, this means that the System Suitability Test has failed; that is, the system is not delivering accurate results. In this case, after clicking the *Evaluate*, *Next*, or *Verify* button, a dialog appears informing the Lab Analyst of which QC results failed conformance and they must choose how to proceed.

When the Lab Analyst clicks the **Continue** button, the *Test Set Invalidate* workflow begins. Depending on how the workflow has been configured, the Analyst can choose whether to continue testing or invalidate the *Test Set*. The recommended workflow configuration moves the *Test Set* to the In Review state and gives the Analyst these three options: * **Continue Testing**: The *Test Set* moves back to the *In Progress* state and the Analyst can continue testing. * **Invalidate Test Set and Retest**: The *Test Set* moves to the *Rejected* state and the *Retest* action runs on all existing *Tests* in the *Test Set*. * **Invalidate Test Set, Resampling Required**: The *Test Set* moves to the *Rejected* state. ## Relevant Permissions In order to manage design data related to System Suitability Testing, Design Data Admins must have *View* permissions to the *Lab Test Definition Version History* control and *Criteria* control for the *Lab Test Definition Criteria* object as well as the *Test Definition Criteria* control for *Spec Data* object. In order to perform data entry related to System Suitability Testing, Lab Analysts must have *Edit* access to the *Invalid Reason* and *Invalid Category* fields on the *Test Set* object. Additionally, to interact with System Suitability Testing, all LIMS Users must have *Read* and *Edit* access to the *Quality Control Sample* object type on the *Lab Sample* object, *Read* access to the *Quality Control Sample Criteria* and *Operation Criteria* object types on the *Lab Test Definition Criteria* object, and *Read* access to the *Quality Control Sample* and *Operational Criteria* fields on the *Spec Execution* object.