GxPアプリ構築のベストプラクティス

GxP環境には独自の要件がありますが、チューリップのアプリ構築と設定によって対応できます。Tulipには、コンプライアンスを確保するための標準化されたベストプラクティスがあります。

この記事では以下をご覧いただけます：

• GxP環境でアプリを構築するためのベストプラクティスと推奨事項のリスト
• 監査証跡のトレーサビリティやデータの完全性など、GXPコンプライアンスを確保するためのベストプラクティスをTulip Appsに実装する方法に関する情報。

この記事で取り上げているベストプラクティス

1. 系図とEDHR/eBRをキャプチャする：
2. プロセスパラメータを管理するためのベストプラクティス（測定単位、小数精度、変数の命名規則など）
3. 各工程における標準情報の表示に関する最低限の慣行
4. 署名ウィジェットによる電子署名の取得
5. 例外の管理と例外によるレビューの有効化
6. Datetimeタイムスタンプの操作と管理
7. プロセスアプリの「一時停止と再開」機能の有効化

1.系図と履歴レコードの取得完了データを使用して、変更不可の履歴レコードを作成する

• **履歴レコードは、チューリップテーブルのレコード（テーブルの行）とコンプリーションデータ（項目/行）をリンクすることで作成されます。**そのため、履歴レコードに必要なテーブルレコードは、アプリの完了が発生すると同時にアプリに読み込まれます。レコードデータを操作する際は、必ずアプリの完了をトリガーロジックに含めてください。
• 履歴レコードは複数の完了からコンパイルされるため、アプリはデータを記録する必要があるプロセスのポイントで "完了 "する必要があります。そのため、実行中にアプリが複数回完了する必要がある場合があります。アプリを完了すると、抵抗力のない変数がクリアされるため、アプリの設計時に考慮する必要があります。

系図と履歴の記録をキャプチャする：完了データを使用して、テーブルを修正する際の完全なトレーサビリティを作成する。

• **テーブルレコードを使用する場合は、コンプリーションでトレーサビリティを確保します：**備考アプリの実行中にテーブルレコードのデータを操作することはリアルタイムで発生し、アプリの完了とは関係ありません。データの同時性を保つために、テーブルのデータ操作をアプリの完了と同じトリガーシーケンスに含める。

系譜と履歴レコードをキャプチャする：完了データを使用して、履歴エントリに対する変更の完全なトレーサビリティを処理する。

• **glossary.デジタルレコード履歴}}エントリの修正は、新しい補完データを追加することでのみ可能です。**補完記録の値を意図的に変更する方法はありません。これは、元のデータが維持されていることを保証するための意図的なものです。
• **簡単に考えると、完了記録はアプリの実行の監査証跡です。**すでに完了記録にコミットされたデータは、追加の完了記録エントリによって修正される。

Appでの修正例修正方法："修正 "としてレコードを定義するオプション変数を使用して、アプリまたはアプリのステップを再度実行する。

• レコードタイプ "という変数を作成し、"ノーマル"、"訂正 "などの標準的な値を割り当て、完了レコードの並べ替えやフィルタリングに使用する。
• ほとんどの場合、取り込まれた日付を使って修正エントリーを並べ替えるだけで十分である。

2.プロセスパラメータを管理するためのベストプラクティス（例：単位、小数部の精度、変数の命名方法など）

• **プロセス・データの測定単位を保存するために、追加のヘルパー変数を使用する。**プロセスおよび生産データでは、測定単位（UOM）を指定することが常に重要です。
• これは、選択可能または静的な値を持つ追加変数（ヘルパー変数）で行います。
• ヘルパー変数は完了記録に保存されます。
• **アプリのトリガーロジックと式を使用して、小数の精度を管理します。**プロセスパラメータによっては、特定の精度（小数点以下の桁数）が必要な場合があります。これはアプリ内でトリガーロジックと式で管理する必要があります。
• 重要な変数を強調するために、明確な変数名を使用する。クリティカルプロセスパラメータ(CPP)、クリティカル品質属性(CQA)
• 特定のプロセスパラメータは、クリティカルプロセスパラメータ（CPP）またはクリティカル品質属性（CQA）として定義する必要があります。
• 現在のところ、Tulipには変数にタグを付ける方法はありません。そのため、最も簡単な方法は、変数名に接頭辞または接尾辞を付けることです。例："temperature_CPP"、"CQA_Assay B "など。

3.各ステップに表示されるべき最低限の標準情報

ユーザーに適切な文脈を提供するため、各ステップには以下の要素を表示すること：

1. アプリで処理されている主な項目の名前または一意の ID（例：バッチ、オーダー、機器、ツール）。場合によっては複数のアイテムが存在する。
2. 以下はアプリのベースレイアウトに存在する必要があります。
   1. アプリ情報/アプリ名
   2. アプリ情報 / アプリバージョン
   3. アプリ情報 / ログインユーザー
   4. App Info / Step Name」(一般的にステップ名はオペレータに有用なプロセスコンテキストを提供するので、目立つフォントサイズで)

4.署名ウィジェットによる電子署名の取得

**署名のコンテキストを提供するために、署名タイトルまたはステップの追加変数キャプチャ/入力を使用します。**電子署名の要件では、署名には以下が含まれることを覚えておいてください。

1. **何のために署名するのか？**署名のコンテキストは、署名ステップ名（バッチ、注文、設備など）に記述できます。
2. **なぜ署名するのか？**変数を使用して、署名ウィジェットの上に署名の理由を記述する。
3. いつ署名したか？ 日付/タイムスタンプは、署名が適用された日時です。署名ウィジェットが完了すると、アプリは自動的にこれを完了データとして取り込みます。

署名のコンテキストをキャプチャするために推奨される方法は、以下のとおりです。

• ステップ名を使用して、電子署名の理由を定義する。
• グループ 電子署名が必要なステップを配置し、グループの最後のステップとして署名ウィジェットを含めます。
• 署名の意図を説明するテキスト入力ラベルまたは単一選択のドロップダウンリストを使用します。
• 署名の前にサマリーステップを作成し、ユーザーに署名内容のコンテキストを提供する。

5.例外の管理と例外によるレビューの有効化

履歴レコードに関連する例外のレビューを可能にするには、次のことが重要です。

• 例外を簡単に識別できるようにするために、アプリ変数を使ってレコードタイプ（通常、訂正、例外など - 1.3 節参照）を定義する。
• **テーブルを使用して、レビュー用の例外を照合します。**すべての例外（欠陥、観察など）は、すべての関連情報（例外の情報、日付/時刻、アプリケーション、オーダー/バッチ、オペレータなど）を含む単一のレコードとしてチューリップテーブルに格納されるべきである。完了データに格納するだけでなく、これらのレコードをバッチやオーダーにリンクすることもできる。
• 例外テーブルには、例外の対象であるアーティファクトをリンクまたは参照する列を含める。例：バッチ、材料、設備、オーダー

6.日付タイムスタンプの操作と管理

1. 完了レコードのタイムスタンプは、タイムゾーンのオフセットを含む UTC で取得されます。
2. **日付と時間のフォーマットは、すべてのアプリのインスタンスレベルで設定できます。**これは "Settings/Date And Time "オプションで行う。

{height="" width="400"}.

1. **日付と時刻のフォーマットはエクスプレッションエディターで設定できます。**日時を表示または入力する場合は、一貫したフォーマットに基づいて日時を表示するようにしてください。
2. GxPの時間フォーマットでは、"04-Jul-2020 "のような明確なフォーマットが必要です。
3. アプリとアナリティクスで日付/時刻の表示をフォーマットするには、式を使用します。
4. 日付は、式エディタのDATETIMETOTEXT関数を使用することで、指定されたフォーマットにフォーマットすることができます。

7.プロセスアプリをキャンセルに強くする／一時停止と再開機能を有効にする

バッチプロセスは何時間も何日も続くことがあります。オペレータがバッチ作業を一時停止し、後で再開できるようにするには、 「一時停止と再開機能」で説明した推奨ソリューションを検討してください。