Les bases de la création d'applications GxP

Cet article vous fournira les connaissances de base pour aborder la construction d'applications dans des environnements GxP.

Cet article suppose une connaissance préalable des concepts de base de Tulip tels que les variables, les tables et les enregistrements d'achèvement.

Le langage

Le style et le langage des applications doivent correspondre à l'usage auquel elles sont destinées. Les procédures opérationnelles standard, les instructions de travail et les méthodes doivent être écrites dans un style impératif.

Version

Lors de la publication d'une application, il est recommandé de décrire la nature des changements (actualisation de l'interface utilisateur, correction d'erreurs ou autres) par rapport à l'application publiée précédemment dans la section des commentaires.

Informations standard à afficher à chaque étape

Les éléments suivants doivent être affichés à chaque étape afin de fournir à l'utilisateur le contexte approprié :

• Le nom ou l'identifiant unique de l'élément principal que l'application est utilisée pour traiter. "Le nom ou l'identifiant unique de l'élément principal que l'application est utilisée pour traiter, c'est-à-dire le lot, la commande, l'équipement ou l'outil qui est utilisé ou traité. Dans certains cas, il peut y avoir plusieurs éléments. Dans la plupart des cas, il convient de créer ou de charger un enregistrement de table contenant les informations au début de l'application.
• L'utilisateur connecté
• La version de l'application
• Le nom de l'étape de l'application

Il est également recommandé d'avoir un bouton de déconnexion sur toutes les étapes déclenchant une action "Déconnexion de l'utilisateur actuel".

Horodatage et format de la date

Les horodatages dans l'enregistrement d'achèvement sont capturés en UTC avec un décalage pour le fuseau horaire. Le formatage de la date et de l'heure peut être défini au niveau de l'instance pour toutes les applications. Cela se fait dans la section "Date et heure" du menu "Paramètres" de l'instance et doit être configuré par un propriétaire de compte.

Capture de la signature électronique avec le widget E-Signature

Afin de se conformer aux réglementations ER/ES (Electronic Records / Electronic Signatures), une signature doit donner un contexte aux signataires :

• "Quoi ?

Contexte de la signature, par exemple lot, commande, équipement, etc.

• "Pourquoi

La raison de la signature, par exemple la libération de l'ordre de traitement.

La structure suivante est recommandée pour les signatures :

• Regrouper les étapes qui nécessitent une signature électronique et inclure le widget de signature électronique dans la dernière étape du groupe.
• Créer une étape récapitulative, le cas échéant, avant le widget, montrant toutes les données pertinentes pour fournir au signataire le contexte de la signature ("Quoi").
• Utiliser le titre du formulaire, par exemple "Signature pour réimpression d'étiquette", et l'étiquette du nom d'utilisateur, par exemple "Superviseur", pour définir la raison de la signature ("Pourquoi").

Lorsque la signature est soumise, Tulip enregistre automatiquement des informations supplémentaires :

• "Qui" a signé le formulaire
• "Quand" la signature a été soumise
• Tout commentaire ajouté

Il est obligatoire d'enregistrer les données actuelles de l'application dans un enregistrement immuable. Ceci peut être réalisé de deux manières :

• En utilisant l'action "Sauvegarder toutes les données de l'application" dans un déclencheur "Action personnalisée" sur le bouton de soumission du widget de signature.
• En terminant l'application, soit en utilisant le paramètre standard "Terminer l'application" pour le bouton de soumission, soit en utilisant une action "Terminer l'application" dans un déclencheur "Action personnalisée".

Action "Sauvegarder toutes les données de l'application

L'action "Enregistrer toutes les données de l'application" enregistre les valeurs actuelles de toutes les variables de l'application ainsi que les valeurs actuelles des champs de tous les enregistrements de table chargés dans un enregistrement d'achèvement de l'application. Les enregistrements d'achèvement sont immuables et ne peuvent pas être supprimés.

Achèvement de l'application

L'achèvement d'une application stocke les données de la même manière que l'action "Enregistrer toutes les données de l'application". De plus, l'achèvement d'une application réinitialise toutes les variables à leur valeur par défaut, mais celles qui ont l'option "effacer à l'achèvement" désactivée. De plus, tous les espaces réservés des enregistrements de table sont effacés. Après l'achèvement d'une application, il est possible de redémarrer la même application depuis le début ou de passer à une étape spécifique au sein de la même application ou d'une autre application. Ceci peut être configuré dans la "transition" utilisée pour effectuer l'achèvement.

Annulation d'application

L'annulation d'une application est identique à l'achèvement d'une application, mais toutes les variables sont réinitialisées à leur valeur par défaut.

Initialisation automatique de l'application

Pour une application qui doit être complétée plusieurs fois au cours de l'exécution, c'est-à-dire en raison de signatures multiples, il est recommandé de stocker son contexte avant chaque achèvement, de sorte que l'application peut être configurée pour restaurer automatiquement son contexte après son redémarrage. Le contexte peut être l'ID des enregistrements de la table, par exemple le lot en cours, et/ou des variables, par exemple un compteur. Il est recommandé de stocker le contexte de l'application dans un tableau en utilisant "App Info : Nom de la station" comme identifiant de l'enregistrement. Cet enregistrement peut être chargé au (re)démarrage de l'application à l'aide d'un déclencheur "App Started". La même approche peut être utilisée pour réaliser une transition transparente vers une autre application.

Des principes similaires peuvent être appliqués pour reprendre l'exécution de l'application après une annulation de l'application, c'est-à-dire en raison d'une déconnexion automatique ou en sélectionnant "Redémarrer" dans le menu du lecteur. Pour ces cas d'utilisation, il est recommandé de stocker un nom d'étape en tant qu'information contextuelle supplémentaire pour l'application à ouvrir après le redémarrage. Il peut s'agir du nom de la dernière étape affichée ou d'une étape spécifique qui doit être ouverte pour la récupération.

Exceptions et activation de l'examen par exception

Il est recommandé d'utiliser une table Tulip pour rassembler toutes les exceptions survenant au cours de l'exécution de l'application. Chaque exception (défaut, observation, etc.) doit être stockée en tant qu'enregistrement unique dans cette Tulip Table, avec toutes les informations pertinentes sur l'exception, c'est-à-dire le type, la description, la date/l'heure, l'application, l'opérateur, etc. En outre, cet enregistrement doit être lié, à l'aide de la fonction "Enregistrements liés", aux enregistrements de tous les artefacts liés à l'exception, c'est-à-dire le lot, la commande, le matériel, l'équipement, la salle, etc.

Enregistrements, correction des enregistrements, historique des enregistrements

Il est recommandé de stocker les données GxP pertinentes en tant qu'enregistrement dans les tables Tulip en se référant aux artefacts pertinents, c'est-à-dire le lot, la commande, le matériel, l'équipement, la pièce, etc.

Il est recommandé de corriger les données GxP pertinentes dans l'enregistrement original, car toute modification sera reflétée dans l'historique de l'enregistrement. La correction doit être soumise au moyen d'un formulaire de signature.

Pour faciliter la recherche des enregistrements, il est recommandé d'attribuer un identifiant systématique et sans ambiguïté à toutes les entrées, par exemple "-".

Historique des enregistrements

Comme décrit ci-dessus, les valeurs des variables sont stockées dans un enregistrement d'achèvement au moment de l'achèvement ou de l'annulation de l'application. En revanche, la manipulation des données d'un tableau se fait en temps réel. Toute modification d'un champ d'un enregistrement de table sera automatiquement enregistrée avec des informations contextuelles (utilisateur, application, version de l'application, station, date et heure) par Tulip.

Chaque enregistrement d'une table Tulip a un historique. Cet historique montrera tous les changements enregistrés, y compris les informations contextuelles (utilisateur, application, version de l'application, station, date et heure).

De plus, l'historique de l'enregistrement montrera les données de toute application complétée ou annulée dans laquelle l'enregistrement est inclus, c'est-à-dire qu'il a été chargé lors de la complétion ou de l'annulation. Cela inclut toutes les signatures électroniques enregistrées lors de ces achèvements/annulations. Les signatures seront affichées dans la chronologie de l'historique de l'enregistrement en fonction de l'horodatage auquel elles ont été apposées. Toutes les autres données d'achèvement seront affichées avec l'horodatage de l'achèvement ou de l'annulation.

Pour en savoir plus

• Meilleures pratiques en matière de GxP
• Utilisation du widget d'historique des enregistrements
• Comment exporter les données de l'application