Buenas prácticas para la creación de aplicaciones GxP

Los entornos GxP tienen requisitos únicos que pueden ser abordados a través de la construcción y configuración de Tulip App. Tulip tiene un conjunto estandarizado de las mejores prácticas para garantizar el cumplimiento que se describen aquí.

En este artículo encontrarás:

• Una lista de las mejores prácticas y recomendaciones para la construcción de Apps en un entorno GxP.
• Información sobre cómo implementar las mejores prácticas dentro de Tulip Apps para garantizar el cumplimiento de GXP, incluyendo la trazabilidad de la pista de auditoría y la integridad de los datos.

:::(Info) (NOTA)Este artículo asume un conocimiento previo de los conceptos básicos de Tulip como variables, tablas y registros de finalización. Por favor, consulte los artículos aplicables según sea necesario. :::

Mejores prácticas cubiertas en este artículo:

1. Captura de genealogía y EDHR/eBR:

1.1 Utilizar los datos de finalización para crear un registro histórico inmutable

1.2 Utilice los datos de finalización para crear una trazabilidad completa al modificar las Tablas

1.3 Utilice los datos de finalización para mostrar la trazabilidad completa de los cambios en los registros históricos
2. Prácticas recomendadas para la gestión de parámetros de proceso (por ejemplo, unidad de medida, precisión decimal y convención de denominación de variables)
3. Prácticas mínimas para la visualización de información estándar en cada paso
4. Captura de firmas electrónicas con widgets de firma
5. Gestión de excepciones y habilitación de la revisión por excepción
6. Trabajar y gestionar marcas de tiempo Datetime
7. Habilitar la funcionalidad 'Pausar y Reanudar' para las Apps de proceso.

1. Capturar la genealogía y el registro histórico: Utilizar los datos de Finalizaciones para crear un registro histórico inmutable

• Los registros históricos se compilan vinculando un registro de Tulip Table (es decir, una fila de una tabla) con datos de finalizaciones (entradas/filas). Cualquier registro de tabla Tulip que se incluya en los datos de finalización puede utilizarse para esta vinculación, por lo que el registro de tabla necesario para el registro histórico se cargará en la aplicación al mismo tiempo que se produce una finalización de aplicación. Asegúrese de incluir las finalizaciones de la aplicación en su lógica de activación cuando manipule los datos del registro.
• Los registroshistóricos se compilan a partir de varias finalizaciones, por lo que las aplicaciones deben "completarse" en los puntos del proceso en los que es necesario registrar los datos. Por lo tanto, puede ser necesario que una aplicación se complete varias veces durante la ejecución. Tenga en cuenta que al completar una aplicación se borran las variables no resistentes y esto debe tenerse en cuenta durante el diseño de la aplicación.

Capture la genealogía y el registro histórico: Utilice los datos de finalización para crear una trazabilidad completa al modificar tablas.

• Cuando trabaje con registros de tablas, asegure la trazabilidad con las finalizaciones: Recordatorio: La manipulación de datos en registros de tablas durante la ejecución de la App ocurre en tiempo real y no está ligada a la finalización de la App. Para mantener la contemporaneidad de los datos, incluya la manipulación de los datos de la tabla en la misma secuencia de activación que la finalización de la App.

Capture la genealogía y el registro histórico: Utilice los datos de finalización para gestionar la trazabilidad completa de los cambios en las entradas históricas.

• La corrección de entradas {{glosario.Historial de registros digitales}} sólo puede realizarse añadiendo nuevos datos de finalización. No hay forma de cambiar intencionadamente los valores de un registro de finalización. Esto es intencionado para asegurar que se mantienen los datos originales.
• Una forma sencilla de verlo es que un registro de finalización es una pista de auditoría de la ejecución de una aplicación. Los datos que ya se han consignado en el registro de finalización se corrigen mediante una entrada adicional en el registro de finalización.

Ejemplo de corrección implementada en aplicacionesCómo realizar la corrección: Ejecute de nuevo la App o los pasos de la App, con una variable opcional que defina el registro como "corrección".

• Cree una variable "Tipo de registro" a la que se le asignen valores estándar como "Normal", "Corrección", etc. que puedan utilizarse para ordenar/filtrar el registro de finalización.
• En la mayoría de los casos basta con utilizar las fechas capturadas para ordenar las entradas de corrección, ya que se trata de un orden cronológico en el que la entrada más reciente es el valor válido.

2. Mejores prácticas para la gestión de parámetros de proceso (por ejemplo, unidad de medida, precisión decimal y prácticas de denominación de variables)

• Utilice variables de ayuda adicionales para guardar la unidad de medida de los datos de proceso. Para los datos de proceso y producción, siempre es importante especificar la Unidad de Medida (UOM), por ejemplo °C, Kg, Litros, Ph., etc.
• Haga esto con una variable adicional (variable de ayuda) que puede ser seleccionada o tiene un valor estático.
• Las variables auxiliares se guardarán en el registro de finalización.
• Utilice la lógica y la expresión del activador de la aplicación para gestionar la precisión decimal. Ciertos parámetros de proceso pueden requerir una precisión específica, es decir, el número de decimales. Esto debe gestionarse en la aplicación mediante la lógica de activación y las expresiones.
• Utilice una nomenclatura clara de las variables para resaltar las variables clave. Parámetros críticos del proceso (CPP) o Atributo crítico de calidad (CQA)
• Algunos parámetros de proceso deben definirse como Parámetros Críticos de Proceso (CPP) o Atributo Crítico de Calidad (CQA).
• Actualmente no hay forma de etiquetar variables en Tulip, por lo que la forma más sencilla de hacerlo es añadiendo un prefijo o un sufijo a los nombres de las variables. Por ejemplo, nombres de variables como "temperature_CPP", "CQA_Assay B", etc.

3. Información estándar mínima que debe mostrarse en cada Paso

Los siguientes elementos deben mostrarse en cada paso para proporcionar al usuario el contexto apropiado:

1. El nombre o ID único del ítem principal que está siendo procesado en la app, Ej. Lote , Orden , Equipo, Herramienta. En algunos casos habrá varios elementos.
2. Lo siguiente debe estar presente en el diseño base de la aplicación.
   1. Información de la aplicación / Nombre de la aplicación
   2. Información de la aplicación / Versión de la aplicación
   3. Información de la aplicación / Usuario conectado
   4. App Info / Step Name" (en un tamaño de fuente destacado, ya que el nombre del paso suele proporcionar un contexto de proceso útil para el operador).

4. Captura de firmas electrónicas con widgets de firma

Utilice el título de la firma o la captura/introducción de variables adicionales en el paso para contextualizar las firmas. Recuerde que los requisitos de firma electrónica dictan que una firma incluya

1. Para qué se firma El contexto de la firma puede describirse en el nombre del paso de firma, por ejemplo, Lote, Pedido, Equipo, etc.
2. ¿Por qué firma? Utilice variables para colocar el motivo de la firma encima del widget de firma.
3. ¿Cuándo se firmó? El sello de fecha/hora indica cuándo se aplicó la firma. La aplicación lo captura automáticamente como datos de finalización cuando se completa el widget de firma.

A continuación se recomiendan algunas formas de capturar el contexto de la firma.

• Utilice el nombre del paso para definir el motivo de la firma electrónica.
• Agrupe los pasos que requieren una firma electrónica e incluya el widget de firma como el último paso del grupo.
• Utilice una etiqueta de entrada de texto o una lista desplegable de selección única que describa el motivo de la firma.
• Cree un paso de resumen antes de la firma para proporcionar al usuario el contexto de lo que está firmando.

5. Gestión de excepciones y habilitación de la revisión por excepción

Lo siguiente es importante para permitir la revisión de excepciones relacionadas con un registro histórico.

• Utilice una Variable de la aplicación para definir el tipo de registro (por ejemplo, normal, corrección, excepción; consulte la sección 1.3) para poder identificar fácilmente las excepciones.
• Utilice una Tabla para recopilar las excepciones para su revisión. Cada excepción (defecto, observación, etc.) debe almacenarse como un único registro en una tabla Tulip que incluya toda la información pertinente (información sobre la excepción, fecha/hora, aplicación, pedido/lote, operario, etc.). Además de almacenarse en los datos de finalización, estos registros pueden vincularse al lote o al pedido.
• En la tabla de excepciones, incluya una columna que vincule o haga referencia al artefacto al que corresponde la excepción. Por ejemplo: lote, material, equipo, pedido

6. Trabajar con marcas de fecha y hora y gestionarlas

1. Las marcas detiempo en el registro de finalización se capturan en UTC con un desfase por zona horaria.
2. El formato de fecha y hora puede establecerse a nivel de instancia para todas las aplicaciones. Esto se hace en la opción "Ajustes/Fecha y Hora".

1. Los formatos de fecha y hora pueden formatearse en el editor de expresiones. Al mostrar o introducir la fecha y la hora, asegúrese de mostrar la fecha y la hora con un formato coherente.
2. Los formatos de hora GxP requieren un formato inequívoco, por ejemplo "04-Jul-2020".
3. Utilice expresiones para dar formato a la visualización de fecha/hora en Apps y Analytics.
4. Las fechas pueden formatearse al formato especificado utilizando la función DATETIMETOTEXT en el editor de expresiones.

7. Haga que las Apps de procesos sean robustas a las cancelaciones / Habilite la funcionalidad Pausar y Reanudar

Los procesos por lotes pueden durar muchas horas o muchos días. Para que un operario pueda interrumpir el trabajo en un lote y retomarlo donde lo dejó en otro momento, considere las recomendaciones de solución que se exponen en "Pausa y reanudación de la funcionalidad".