Práticas recomendadas para a criação de aplicativos GxP

Os ambientes GxP têm requisitos exclusivos que podem ser atendidos por meio da criação e configuração de aplicativos da Tulip. A Tulip tem um conjunto padronizado de práticas recomendadas para garantir a conformidade, que são descritas aqui.

Neste artigo, você encontrará:

• Uma lista das melhores práticas e recomendações para a criação de aplicativos em um ambiente GxP
• Informações sobre como implementar as melhores práticas nos aplicativos Tulip para garantir a conformidade com GXP, incluindo rastreabilidade de trilha de auditoria e integridade de dados.

:::(Info) (OBSERVAÇÃO)Este artigo pressupõe conhecimento prévio dos conceitos básicos do Tulip, como variáveis, tabelas e registros de conclusão. Consulte os artigos aplicáveis conforme necessário.:::

Práticas recomendadas abordadas neste artigo:

1. Captura de genealogia e EDHR/eBR:

1.1 Use os dados de conclusão para criar um registro de histórico imutável

1.2 Use os dados de conclusão para criar rastreabilidade total ao modificar tabelas

1.3 Use os dados de conclusão para mostrar a rastreabilidade total das alterações nos registros históricos
2. Práticas recomendadas para gerenciar parâmetros de processo (por exemplo, unidade de medida, precisão decimal e convenção de nomenclatura de variáveis)
3. Prática mínima para exibição de informações padrão em cada etapa
4. Captura de assinaturas eletrônicas com widgets de assinatura
5. Gerenciar exceções e permitir a revisão por exceção
6. Trabalhar com e gerenciar carimbos de data e hora
7. Habilitar a funcionalidade "Pause & Resume" para aplicativos de processo.

1. Capture registros de genealogia e histórico: Use os dados de conclusões para criar um registro de histórico imutável

• Os registros de histórico são compilados vinculando-se um registro da tabela Tulip (ou seja, linha em uma tabela) com dados de conclusões (entradas/linhas). Qualquer registro de tabela Tulip incluído nos dados de conclusões pode ser usado para essa vinculação, portanto, o registro de tabela necessário para o registro de histórico será carregado no aplicativo ao mesmo tempo em que ocorrer uma conclusão de aplicativo. Certifique-se de incluir as conclusões do aplicativo na sua lógica de acionamento ao manipular os dados do registro.
• Os registros de histórico são compilados a partir de várias conclusões, portanto, os aplicativos devem ser "concluídos" nos pontos do processo em que os dados precisam ser registrados. Portanto, pode ser necessário que um aplicativo seja concluído várias vezes durante a execução. Observe que a conclusão de um aplicativo limpa as variáveis não persistentes e isso deve ser considerado durante o design do aplicativo.

Capture registros de genealogia e histórico: Use os dados de conclusão para criar rastreabilidade total ao modificar tabelas

• Ao trabalhar com registros de tabela, garanta a rastreabilidade com conclusões: Lembrete: A manipulação de dados em registros de tabela durante a execução do aplicativo ocorre em tempo real e não está vinculada à conclusão do aplicativo. Para manter a contemporaneidade dos dados, inclua a manipulação dos dados da tabela na mesma sequência de acionamento que a conclusão do aplicativo.

Capture registros de genealogia e histórico: Use os dados de conclusão para lidar com a rastreabilidade total das alterações nas entradas históricas

• A correção dos registros Digital Record History só pode ser feita adicionando novos dados de conclusão. Não há como alterar valores em um registro de conclusão, intencionalmente. Isso é intencional para garantir que os dados originais sejam mantidos.
• Uma maneira simples de pensar nisso é que um registro de conclusão é uma trilha de auditoria da execução de um aplicativo. Os dados que já foram confirmados no registro de conclusão são corrigidos por uma entrada adicional no registro de conclusão.

Exemplo de correção implementada em aplicativosComo fazer a correção: Execute o aplicativo ou as etapas do aplicativo novamente, com uma variável opcional que define o registro como uma "correção".

• Crie uma variável "Tipo de registro" à qual são atribuídos valores padrão, como "Normal", "Correção" etc., que podem ser usados para classificar/filtrar o registro de conclusão.
• Na maioria dos casos, basta usar as datas capturadas para classificar as entradas de correção, pois essa é a ordem cronológica, sendo a entrada mais recente o valor válido.

2. Práticas recomendadas para gerenciar parâmetros de processo (por exemplo, unidade de medida, precisão decimal e práticas de nomeação de variáveis)

• Use variáveis auxiliares adicionais para salvar a unidade de medida dos dados do processo. Para dados de processo e produção, é sempre importante especificar a Unidade de Medida (UOM), por exemplo, °C, Kg, Litros, Ph, etc.
• Faça isso com uma variável adicional (variável auxiliar) que possa ser selecionada ou tenha um valor estático.
• As variáveis auxiliares serão salvas no registro de conclusão.
• Use a lógica e a expressão do aplicativo Trigger para gerenciar a precisão decimal. Certos parâmetros de processo podem exigir uma precisão específica, ou seja, o número de casas decimais. Isso precisa ser gerenciado no aplicativo por meio de lógica de acionamento e expressões.
• Use uma nomenclatura clara de variáveis para destacar as principais variáveis, por exemplo****Parâmetros críticos de processo (CPP) ou Atributo crítico de qualidade (CQA)
• Certos parâmetros de processo precisam ser definidos como Parâmetros Críticos de Processo (CPP) ou Atributo Crítico de Qualidade (CQA)
• Não existe uma maneira atual de marcar variáveis no Tulip, portanto, a maneira mais simples de fazer isso é adicionar um prefixo ou sufixo aos nomes das variáveis. Por exemplo, nomes de variáveis como "temperature_CPP", "CQA_Assay B", etc.

3. Informações padrão mínimas a serem exibidas em cada etapa

Os seguintes elementos devem ser exibidos em cada etapa para fornecer ao usuário o contexto adequado:

1. O nome ou a ID exclusiva do item principal que está sendo processado no aplicativo, por exemplo, Lote, Pedido, Equipamento, Ferramenta. Em alguns casos, haverá vários itens.
2. Os itens a seguir devem estar presentes no layout básico do aplicativo.
   1. O 'App Info / Nome do aplicativo'.
   2. As 'Informações do aplicativo / Versão do aplicativo'
   3. As "Informações do aplicativo / Usuário conectado
   4. O 'App Info / Step Name' (em um tamanho de fonte proeminente, pois geralmente o nome da etapa fornecerá um contexto de processo útil para o operador).

4. Captura de assinaturas eletrônicas com widgets de assinatura

Use o título da assinatura ou a captura/entrada de variável adicional na etapa para dar contexto às assinaturas. Lembre-se de que os requisitos de assinatura eletrônica determinam que uma assinatura inclua

1. O que você está assinando? O contexto da assinatura pode ser descrito no nome da etapa de assinatura, por exemplo, lote, pedido, equipamento etc.
2. Por que você está assinando? Use variáveis para colocar o motivo da assinatura acima do widget de assinatura.
3. Quando foi assinada? O carimbo de data/hora indica quando a assinatura foi aplicada. O aplicativo captura isso automaticamente como dados de conclusão quando o widget de assinatura é concluído.

A seguir, algumas maneiras recomendadas de capturar o contexto da assinatura.

• Use o nome da etapa para definir o motivo de uma assinatura eletrônica.
• Coloque etapas de grupo que exijam uma assinatura eletrônica e inclua o widget de assinatura como a última etapa do grupo.
• Use um rótulo de entrada de texto ou uma lista suspensa de seleção única que descreva a intenção da assinatura.
• Crie uma etapa de resumo antes da assinatura para fornecer ao usuário o contexto do que ele está assinando.

5. Gerenciar exceções e permitir a revisão por exceção

O que se segue é importante para permitir a revisão de exceções relacionadas a um registro de histórico.

• Use uma variável de aplicativo para definir o tipo de registro (por exemplo, normal, correção, exceção - consulte a seção 1.3) para permitir que as exceções sejam facilmente identificadas.
• Use uma tabela para agrupar as exceções para revisão. Cada exceção (defeito, observação etc.) deve ser armazenada como um único registro em uma tabela Tulip, incluindo todas as informações relevantes (informações sobre a exceção, data/hora, aplicativo, pedido/lote, operador etc.). Além de serem armazenados nos dados de conclusão, esses registros podem ser vinculados ao lote ou à ordem.
• Na tabela de exceções, inclua uma coluna que vincule ou faça referência ao artefato ao qual a exceção se refere. Por exemplo: lote, material, equipamento, ordem

6. Trabalho e gerenciamento de carimbos de data e hora

1. Os carimbos de data e hora no registro de conclusão são capturados em UTC com um deslocamento para o fuso horário.
2. A formatação de data e hora pode ser definida no nível da instância para todos os aplicativos. Isso é feito na opção "Settings/Date And Time" (Configurações/Data e Hora).

1. Os formatos de data e hora podem ser formatados no editor de expressões. Ao exibir ou inserir a data e a hora, certifique-se de exibir a data/hora com base em um formato consistente.
2. Os formatos de hora GxP exigem um formato não ambíguo, por exemplo, "04-Jul-2020"
3. Use a expressão para formatar a exibição de data/hora nos aplicativos e no Analytics.
4. As datas podem ser formatadas de acordo com o formato especificado usando a função DATETIMETOTEXT no editor de expressões.

7. Tornar os Apps de processo resistentes a cancelamentos / Ativar a funcionalidade Pause & Resume

Os processos em lote podem durar muitas horas ou muitos dias. Para permitir que um operador pause o trabalho em um lote e continue de onde parou em um momento posterior, considere as recomendações de solução discutidas em "Funcionalidade de pausa e retomada".