Best Practices for GxP App Building

GxP environments have unique requirements that can be addressed through Tulip App building and configuration. Tulip has a standardized set of best practices to ensure compliance that are described here.

In this article you'll find:

• A list of the best practices and recommendations for building Apps in a GxP environment
• Information on how to implement the best practices within Tulip Apps to ensure GXP compliance, including audit-trail traceability and data integrity.

Best practices covered in this article:

1. Capture genealogy and EDHR/eBR:
   1.1 Use the Completion data to create an unchangeable history record
   1.2 Use the completions data to create full traceability when modifying Tables
   1.3 Use the completions data to show full traceability of changes to historic entries
2. Best Practices for managing process parameters (e.g., unit of measure, decimal precision, and variable naming convention)
3. Minimum practice for display of standard information on each step
4. Capturing Electronic Signatures with signature widgets
5. Managing exceptions and enabling review by exception
6. Working with and managing Datetime timestamps
7. Enable 'Pause & Resume' functionality for process Apps.

1. Capture genealogy and history record: Use the Completions data to create an unchangeable history record

• History records are compiled by linking a Tulip Table record (i.e. row in a table) with completions data (entries/rows). Any Tulip table Record that is included in completions data can be used for this linking, therefore the table record needed for the history record will be loaded in the App at the same time that an App completion occurs. Be sure to include app completions in your trigger logic when manipulating record data.
• History records are compiled from multiple completions, therefore Apps should "Complete" at the points in the process where data needs to be logged. It therefore may be required for an App to complete multiple times during execution. Note that completing an App clears non-persistant variables and this should be considered during App design.

Capture genealogy and history record: Use the completions data to create full traceability when modifying tables

• When working with Table Records, ensure traceability with completions: Reminder: Manipulation of data in table records during App execution happens in real time and is not tied to App Completion. To keep data contemporaneous, include table data manipulation in the same trigger sequence as the App completion.

Capture genealogy and history record: Use the completions data to handle full traceability of changes to historic entries

• Correction to Digital Record History entries can only be done by adding new completion data. There is no way to change values in a completion record, intentionally. This is intentional to assure original data is maintained.
• A simple way to think of it is, a completion record is an audit trail of an App executing. Data that has been already committed to the completion record is corrected by an additional completion record entry.

Example of correction implemented in Apps
How to make the correction: Execute the App or App steps again, with an optional variable that defines the record as a "correction."

• Create a Variable “Record Type” that is assigned standard values such as “Normal”, “Correction”, etc. that can be used to sort/filter the completion record.
• In most cases it is enough to use the captured dates to sort through correction entries, as this is chronological order with the most recent entry being the valid value.

2. Best Practices for managing process parameters (e.g., unit of measure, decimal precision and variable naming practices)

• Use additional helper Variables to save the Unit Of Measurement for process data. For process and production data, it is always important to specify Unit of Measurement (UOM), e.g. °C, Kg, Liters, Ph., etc.

• Do this with an additional variable (helper variable) that can either be selected or has a static value.
• Helper variables will be saved in the completion record.

• Use app Trigger logic and expression to manage decimal precision. Certain process parameters may require a specific precision, i.e., number of decimal places. This needs to be managed in the App through trigger logic and Expressions.
• Use clear variable naming to highlight key variables. e,g. Critical Process Parameters (CPP), or Critical Quality Attribute (CQA)

• Certain process parameters have to be defined as Critical Process Parameters (CPP), or Critical Quality Attribute (CQA)
• There is no current way to tag variables in Tulip so the simplest way to do this is by adding either a prefix or suffix to variable names. E.g. variable names such as “temperature_CPP”, “CQA_Assay B”, etc.

3. Minimum standard information to be displayed on each Step

The following elements should be shown on each step in order to provide to the user the appropriate context:

1. The name or unique ID of the main item that is being processed in the app, E.g. Batch , Order , Equipment, Tool. In some cases there will be multiple items.
2. The following should be present on the App's Base Layout.
   1. The 'App Info / App Name'.
   2. The 'App Info / App Version'
   3. The 'App Info / Logged-In User'
   4. The 'App Info / Step Name' (in a prominent font size as commonly the Step name will provide useful process context to the operator.)

4. Capturing e-signatures with signature widgets

Use Signature title or additional Variable capture/input on step to give context for the signatures. Remember that e-signature requirements dictate that a signature includes

1. What are you signing for? The context for the signature can be described in the signature step name, e.g. Batch, Order, Equipment, etc.

2. Why are you signing? Use variables to put the reason for the signature above the signature widget.

3. When was it signed? The date/time stamp is when the signature was applied. The app automatically captures this as completion data when the signature widget is completed.

The following are a few recommended ways to capture context of the signature.

• Use the step name to define the reason for an e-signature.
• Place group Steps that require an e-signature and include the signature widget as the last step in the group.
• Use a text input label or single select dropdown list that describes the intent of signature.
• Create a summary step before the signature to provide the user the context of what they are signing for.

5. Managing exceptions and enabling review by exception

The following is important to allow review of exceptions related to a history record.

• Use an app Variable to define the record type (e.g., normal, correction, exception - see section 1.3) to enable exceptions to be easily identified.
• Use a Table to collate the exceptions for review. Every exception (defect, observation, etc.) should be stored as a single record in a Tulip table including all relevant information (information on exception, date/time, app, order/batch, operator etc.). In addition to being stored in the completion data, these records can be linked to the batch or order.
• In the exception table, include a column that links or references the artifact that the exception is for. For example: batch, material, equipment, order

6. Working with and managing date time stamps

1. Timestamps in the completion record are captured in UTC with an offset for time zone.
2. Date and time formatting can be set at the instance level for all Apps. This is done in the "Settings/Date And Time" option.

3. Datetime formats can be formatted in the Expression editor. When displaying or entering date time make sure to display the date/time based on consistent format.

• GxP time formats require unambiguous format, e.g. “04-Jul-2020”
• Use expression to format date/time display in Apps and Analytics.
• Dates can be formatted to the specified format by using the DATETIMETOTEXT function in the expression editor.

7. Make process Apps robust to cancellations / Enable Pause & Resume functionality

Batch processes may last many hours or many days. To enable an operator to pause work on a batch, and pick up where they left off at a later time consider the solution recommendations as discussed in 'Pause and Resume Functionality'.