How to use the GxP App Template
  • 04 Oct 2024
  • 7 Minuten zu lesen
  • Mitwirkende

How to use the GxP App Template


The content is currently unavailable in German. You are viewing the default English version.
Artikel-Zusammenfassung

The purpose of the article is to introduce the GxP App Template as a starting point to accelerate your app building process. This guides you through the app’s data structure, the reusable components that you can configure without needing any code, and additional resources to help you become a GxP app building expert.

Data Structure Within the GxP App Template: Completion and Tables

This app utilizes both tables and completion records to store various types of information. When the information is designed to be reused by other applications, it is saved into a Table. Information that we only need for review purposes is stored in the Completion data. All the tables utilized by the GxP App Template and the applications in the Composable MES for Pharma are built using Tulip’s Common Data Model for Pharma.

Tables Used by the Composable MES for Pharma

The apps in the Composable MES for Pharma are interconnected and work together with the Common Data Model for Pharma. The Common Data Model for Pharma provides a starting point for organizing and collecting data in tables that make sense, and are easily extended with new apps, helping your team scale faster and solve challenges.

Reusable Building Blocks in the Applications

Pause and Resume Within Applications

Most of the applications within the Composable MES for Pharma are resumable, a feature enabled by built-in logic. This means progress can be paused and resumed at a later time if needed.

Each process application includes a trigger on its base layout. This trigger saves the step name in the Process Flow table.

Multiple triggers are present at the start of each process application. Their function is to check for an in-progress status for the chosen batch. If an in-progress status exists, the application resumes from the step where it was left off.

Navigation triggers

Within the app suite, we use four different kinds of navigation triggers: Next, Previous, Go to, and Routing.
The Next trigger, as described by its name, navigates the app to the next step.

Screenshot 2024-09-12 at 15.07.06.png

The Previous trigger navigates the app to the previous step. However, instead of using the previous option within the trigger, we use the name of the previous step. This is to enforce that Previous navigation always refers to the main sequence of steps, and not navigates to a secondary step such as Comment. For example, if a user creates a comment, returns to the ongoing process step, and then tries to navigate back to the previous process step, using a Previous logic would inadvertently navigate them to the comment step instead of the previous step in the sequence.
Screenshot 2024-09-12 at 15.07.29.png

The Go to trigger is also used in the app suite. Instead of going to the next or previous step, this trigger goes to a specific step defined within the trigger itself.
Screenshot 2024-09-12 at 15.08.10.png

The Routing trigger navigates the app to different steps based on certain conditions. Which step the app navigates to depends on which condition is fulfilled.
Screenshot 2024-09-12 at 15.07.55.png

Comments, Exceptions, and Corrections

Across all applications in the Composable MES for Pharma, we've used uniform rules for creating comments, exceptions, and corrections.
Comments within the app suite serve as a tool for users to escalate or flag unexpected issues. Each application includes a Report comment button as part of its base layout. Clicking this button navigates the user to a Comment step, where they describe the issue, optionally accompanied by a picture. By clicking the Log Comment button, the application creates a record in the Comments & Exceptions table.
Life Sciences Suite 1.png

In the Composable MES for Pharma, exceptions are used when a deviation from the process is anticipated (for instance, when an inspection value fails compared to a given set of limits). App suites include exception steps based on occurrence, most often following the step where a deviation could occur. On the potential deviation step, a condition built into the navigation button checks whether the predicted process is proceeding as expected. If it is, the exception step is skipped; if it isn't, the app navigates to the subsequent step, the Exception step. Here, users must create an exception to continue the process.
Life Sciences Suite 2.png

Corrections within the app suite are utilized by the app users to record reasons for navigating back or altering previously provided information. An Is correction Boolean variable is used throughout the suite on steps where navigation to the previous steps is possible. This variable is set to No by default. The variable Is correction flips to true if the user navigates back within the app.

When the next button is clicked, the app evaluates the Is correction variable. If it's false, it proceeds to the next step. If true, the app saves the step name and redirects to the correction step. In the Corrections step, users must provide a reason for the information change and can optionally include a picture. Clicking on the Create Correction button triggers the app to log this in the Correction table, resets the Is correction variable to No, and navigates back to the step based on the previously saved step name. The corrections can be reviewed by inspecting the table records.

Screenshot 2024-09-12 at 15.33.25.png

Data Validations in Applications

In the Composable MES for Pharma, there are three different methods of validating information in apps
The first method involves using the widget's validation rules. In the example below, the Next button remains disabled unless the checkbox has been selected.

Screenshot 2024-09-17 at 13.46.45.png

The second way demonstrates the utilization of validation rules in number input widgets. Initially, a rule specifying a range is applied: if the input number falls outside this range, the button remains disabled. Additionally, another rule mandates that number input fields are completed; the button is inactive until this happens.
Screenshot 2024-09-17 at 13.47.08.png

The final method is applied directly to the button action. An expression connected to the button checks the scale's cleanliness status. If the status isn't CLEAN, the button stays disabled.

Screenshot 2024-09-17 at 13.47.31.png

Electronic Signature Widget

In order to make compliance simple and natively part of the Tulip platform, the electronic signature widget offers a way to sign data within Tulip. In accordance with 21 CFR Part 11, this widget provides a legally binding representation of a physical signature. The signature is immutable and recorded within your application Completion data. It can't be reassigned, transferred, or falsified. In the Composable MES for Pharma, we use the Electronic Signature Widget.
For signed-in users, a completion record can be used to replace the signature. The signature widget is typically used for check-bys. Thus, in the example below, a single signature widget allows the user to sign off the process. For additional quality assurance, you can place two signatures in a single step to show who performed and reviewed/approved an action.

Screenshot 2024-09-17 at 13.50.01.png

Record History Widget

The Record History Widget enables data review in a strictly GxP-compliant way. The widget is configured to show all the changes that have been made to a specific artifact (table record) such as a batch or a material. To enable the use of the widget use the same set of tables throughout your process applications and in the review app add the tables to the widget in the Linked Placeholder.
Screenshot 2024-09-17 at 13.51.17.png

Configuration

In-app help

All applications in the Composable MES for Pharma includes in-app help. These are short descriptions of the Required setup steps and App builder tips to support further customization. After downloading the app make sure to read these instructions and then delete them before running the application.

Additional Resources

App Examples and Templates

The Composable MES for Pharma includes app examples and templates.
App examples are applications with in-built, predefined information that helps users understand the app, and test or demonstrate it. Each application represents a specific process step that occurs on your production floor. Review their respective articles or Library web pages to learn more.
Templates serve as starting points by providing reusable building blocks that you can easily tailor for a wide range of processes. Each template has built-in GxP best practices to help automate logging entries, ensure data security, and reduce errors.
By pairing app examples and templates together in the Composable MES for Pharma, you can easily understand, test, and deploy your own versions of these apps to accelerate your development process. After tailoring these templates to your operations, you can standardize or distribute them and allow local configurations to accelerate global deployment projects.

References

Composable MES for Pharma
Production Management app suite
Common Data Model for Pharma
Electronic Logbook


War dieser Artikel hilfreich?