ラボにおけるERESとCSV【第120回】

FDA 483におけるデータインテグリティ指摘(90)


7.483における指摘(国内)
前回より引き続き、国内企業に対するFDA 483に記載されたデータインテグリティ観察所見(Observation)の概要を紹介する。

■ VVVV社 2023/5/26
施設:原薬工場

■ Observation 1
GMP管理に係るソフトウェアをバリデートしていない。とくに:
以下の入力や維持に使用しているERPのソフトウェアをバリデートしていない。
✓    原材料のテスト仕様
✓    製品のテスト仕様
✓    テスト結果
✓    ロット番号
✓    有効期限の計算
✓    ラベル発行
ソフトウェアバリデーションが2013年に実施されたが、貴社の用途を満たすことができるか否かを評価しておらず、バリデーション要件を満たしていない。
 

ERP(Enterprise Resource Management Planning:企業資源計画、統合基幹業務システム)

★解説:ERPのバリデーション
ERPは全社会計系の基幹システムでありGMPバリデーションの適用外であるとしていた企業が一昔前にはあった。また、会計系であるので頻繁に改修が行われるため、その都度バリデーションをやり直すのは現実的ではないと言っていた企業もあった。しかし、ERPが純粋な会計システムから機能発展するとともに、本483に記載された上記のようなGMPに係る機能がERPに含まれるようになってきた。導入するERPにGMPに係る機能が含まれている場合、その機能のバリデーションは必須である。

FDAのGMP査察においてSAPなどのERPが指摘された事例を以下に紹介する。
➣    2016/2/26 インド
製品および材料の在庫管理にSAPが使用されているが、倉庫のどこに製品が格納されているか示すことができなかった。
➣    2016/4/8 ドイツ
影響を受けた製品の(在庫変動等の)変更が、現場で使用されているSAPに記録されていなかった。
➣    2017/4/28 インド
SAPからCOA(分析証明書)を変更できるが変更がいつ行われたか判らない。にもかかわらず品質部門はそのままCOAを発行している。
➣    2017/5/10 インド
ページ番号を印字するなどしてSAPにより記録用紙を出力している。記録用紙にはコピー防止策が施されているが効果は不十分であった。
➣    2017/8/11 米国
管理状態にない電子書式を使用して予防保全の内容や頻度などの情報をSAPシステムに入力し、予防保全活動をスケジューリングしている。
➣    2017/9/8 メキシコ
製品リリースや隔離にSAPが使用されているが、機能が正確であることが検証されていない。データインテグリティを保証するのに必要な監査証跡がSAPにない。
➣    2017/11/11 インド
SAPにより材料の保管期限管理をしているとのことであるが、SAPダウン時にどのように期限管理をするのか規定していない。
➣    2017/12/13 インド
不適合材料の使用防止、原材料の承認、製品リリースにSAPが使用されているが、バリデートされていない。
➣    2019/7/19 インド
倉庫管理にSAPを使用しているが、SAPデータベースの動きがおかしい。
➣    2019/7/19 インド
SAP在庫管理システムを適切にバリデートしていない
➣    2019/10/25 日本
倉庫の職員がSAP R3の使用者教育をうけていなかった。SAPは倉庫管理システムと連携しており、製品がリリースされたかテスト中であるかのステータスを記録している。

 

★解説:ERPのカテゴリ分類とトレーサビリティマトリクス
「ソフトウェアバリデーションが2013年に実施されたが、貴社の用途を満たすことができるか否かを評価していない」とのことである。GMP管理に係る要件はURS(User Request Specification:ユーザー要求仕様)に記載し、各要件がどのように検証されたかをトレーサビリティマトリクスにまとめるとよい。

ERPは一般的に下記カテゴリーのソフトウェアが混在して構成されている。
➣    カテゴリー3ソフトウェア
標準ソフトウェア(全ユーザー企業に共通のソフトウェア)。設定によらず実現される機能が供給者により保証されている場合、その機能の検証はDQにより代替えできる。ユーザーによる設定により実現される機能は、ユーザーが実際に必要な設定を行い、期待通りの機能が実現できたかを検証する必要がある。
➣    カテゴリー4ソフトウェア
ユーザー要求を実現するようユーザー企業ごとに標準ソフトウェアパッケージを構成設定したソフトウェア。ERPに対するユーザー要求はユーザー企業ごとに異なるので、ユーザーごとに構成設定したカテゴリー4のソフトウェアで実現されることが多い。
➣    カテゴリー5ソフトウェア
ユーザー要求を実現するようユーザー企業ごとに個別開発したソフトウェア。カテゴリー4ソフトウェアにより実現できないユーザー要求機能はカテゴリー5ソフトウェアにより実現させる。たとえば、標準機能として備わっていない他システムとの連携機能を個別開発するなど。

 

ひとつのシステムに異なるカテゴリのソフトウェアが混在している場合のトレーサビリティマトリクスの例は、連載第118回を参照されたい。

 

 

執筆者について

経歴 ※このプロフィールは掲載記事執筆時点での内容となります

連載記事

コメント

コメント

投稿者名必須

投稿者名を入力してください

コメント必須

コメントを入力してください

セミナー

eラーニング

書籍

CM Plusサービス一覧

※CM Plusホームページにリンクされます

関連サイト

※関連サイトにリンクされます