ASTROM通信バックナンバー

 ～安全な医薬品の安定供給をご支援する～

こんにちは

ASTROM通信担当の橋本奈央子です。

 

秋らしくなってきましたが、いかがお過ごしでいらっしゃいますか。

 

今回も前回に引き続き、2021年7月1日に発効したPIC/Sガイドライン「GMP/GDP環境での

データ管理とインテグリティに関する適正管理基準（PI 041-1」について見ていきたい

と思います。

 

出典

https://picscheme.org/docview/4234

 

 

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

PIC/S　GUIDANCE

GOOD PRACTICES FOR DATA MANAGEMENT AND INTEGRITY IN REGULATED GMP/GDP ENVIRONMENTS ◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

９章　コンピュータ化システムに関するデータ・インテグリティの留意事項(続き)             

9.6　コンピュータ化システムの監査証跡

＜監査証跡＞

■１－期待

コンピュータ化システムの調達と実装を行う時、データ・マネジメントとインテグリティ

の要件が考慮されるべきである。会社は、適切な電子の監査証跡機能を含むソフトウエア

を選択すべきである。

会社は、電子の監査証跡機能を含むソフトウエアを実装するために、購入や古いシステム

のアップグレードに努めるべきである。

一部のとてもシンプルなシステムは、適切な監査証跡機能が欠けていることが認識されて

いる。しかし、データの正確性を立証するために、代わりの手順が実装されるべきである。

（例：管理の手順、第二のチェックと管理）

追加のガイドラインは、ハイブリットシステムに関する9.10章にある。

個々の手動の作業に関連する重要なデータの全ての変更と削除が記録され、ALCOA+の

原則を満たすことを保証するために、システムのバリデーション中に、監査証跡機能

は検証されるべきである。

規制を受けるユーザは、システム内の監査証跡の性質と機能を理解し、適格性の評価中に、

GMP/GQPの各監査証跡の関連性を判断し、重要でGMP/GQPに関連するデータの監査証跡の

正しい管理と設定を保証するために、いろいろな監査証跡のアセスメントを実施すべき

である。これを行うことは、どの監査証跡と、監査証跡内のどのデータが、制定された

頻度でのレビュにおいて意義があるかを判断するのに重要である。例えば、監査証跡の

レビュのアセスメントは次のことに重点をおくことができる：

-データの変更や修正に関する入力/データの特定とレビュ

-例外のレビュ

–異常または許可されない活動への注目

-パラメータ/データの変更を許可する欠点のあるシステム　または　活動が修正に

 対して無防備な箇所

-注意：パラメータ/データの変更を防ぐ承認の設定がある、または、構成設定への変更

 を防ぐアクセス制限を持った、うまく設計されたシステムは、関連する監査証跡を詳細

 に調査する必要性がないかもしれない。

監査証跡機能はいつも使用可能で機能が固定されていなければならない。監査証跡機能

の動作の停止、削除、修正が可能であってはならない。もし管理者ユーザが、監査証跡

機能の動作の停止、削除、修正をすることが可能ならば、監査証跡は自動入力がされる

べきである。

会社は、監査証跡内の必要なデータを判断し、方針とプロセス、リスクマネジメントの

原則に従った監査証跡のレビュについてまとめた手順を実装すべきである。各操作に

関連する重要な監査証跡は、重要なデータとそれに対する変更が許容可能であると保証

するために、操作完了のレビュの前（例：ロットのリリース判定前）に、操作に関連

する他の全ての記録と一緒に独立してレビュされなければならない。このレビュは、

データの発生した部署によって実施され、必要であれば品質部門により確認されるべき

である。（例：自己点検または調査活動の間）

重要でない監査証跡のレビュは、事前に定めた頻度で、システムのレビュ中に実施

することができる。このレビュは、データの発生した部署によって実施され、必要で

あれば品質部門により確認されるべきである。（例：ロットのリリース判定、自己点検、

調査活動の間）

■１－期待を満たさない場合の潜在的なリスク/チェック項目

・バリデーション文書は、監査証跡が機能的で、システム内の全ての活動、変更、

  その他のトランザクションが全てのメタデータと共に記録されていることを示さな

　ければならない。

・監査証跡が定期的に（品質リスクマネジメントの原則に従って）レビュされ、矛盾

　は調査されていることを確認せよ。

・もし電子的な監査証跡システムがない場合、完全な監査証跡の（統合システムまたは

　バリデートされたインタフェースを使用した独立した監査ソフトウエア）システムが

　利用可能になるまで、データへの変更を示すための紙ベースの記録は容認される。

　これらのハイブリッドのシステムは、それらが、PIC/S GMPガイドラインのAnnex11

　に記述されているような、統合された監査証跡と同等である場合に認められる。

・適切な監査証跡のレビュの不履行は、操作された、または、誤りのあるデータが

　品質部門及び/またはオーソライズド・パーソンによりうっかり承認されうる。

・どのデータが重要で、どの変更や削除が記録されるべきか（監査証跡）の明確な詳細

　が文書化されなければならない。

――――――――――――――――――――――――――――――――――――――――

■２－期待

監査証跡機能が利用可能な場合、電子ベースのシステムに関する監査証跡機能は評価

され、監査の目的のために、データの収集、削除、上書き、変更に関するいかなる重要

な活動も保存するために適切に設定されていなければならない。

監査証跡は、重要なデータに関する、全ての手動で開始されたプロセスを記録するため

に設定されていなければならない。

システムは、登録と電子記録の生成、修正、削除の活動の日時を独立して記録した、

安全なコンピュータが生成したタイムスタンプのついた監査証跡を提供しなければ

ならない。

監査証跡は、以下のパラメータを含んでいなければならない。

-その活動を始めたユーザの詳細

-どんな活動が行われ、何が変更されたか、新旧の値を含む

-いつ、その活動が行われたか、日時を含む

-なぜその活動が行われたか（理由）

-データの変更または修正の場合、変更を許可した職員の名前

監査証跡は、電子記録の生成、修正、削除に関するイベントの経過の復元を可能に

しなければならない。

システムは監査証跡を印刷し、電子コピーを提供できなければならない。監査証跡は、

システムで見てもコピーで見ても意味がわかるフォーマットで利用可能でなければなら

ない。

可能であれば、監査証跡は、コンピュータシステム内で動的な機能性を保つべきである。

（例：検索機能やスプレッドシートなどへのエクスポート）

注意：監査証跡は、変更がPQS(医薬品品質システム)のもとで適切に管理され承認される

ために必要とされる変更管理システムと混同されるべきではない。

■２－期待を満たさない場合の潜在的なリスク/チェック項目

・全ての重要な情報と関連する情報が保存されることを保証するために、監査証跡の

　フォーマットを確認せよ。

・監査証跡は、全ての前の値を含まなければならない。記録の変更で、前に記録された

　情報を不明確にしてはいけない。

・監査証跡は、正確な時間に、実際の活動の時間を反映して記録されるべきである。

　監査証跡に、複数の一連の作用に関し、同時に記録する、もしくは、全ての作用が

　完了した時に1つだけ記録するのは、特に、別々の作用、または一連の作用が重要な

　場合（例：4つの原料を１つの混合容器に追加する際の電子記録）、データ・インテ

　グリティの期待に従っていないかもしれない。

　もし、追加の順番が重要管理点（CCP）の場合、各追加は、タイムスタンプと共に

　個々に記録されなければならない。もし、追加の順番がCCPでない場合、全4原料の

　追加は１つのタイムスタンプの活動として記録することができる。

 

9.7　コンピュータ化システムのデータ収集/入力

■１－期待

システムは、方法が手動でも自動でも、正しいデータの保存のために設計されるべきで

ある。

〇手動入力の場合：

-重要データの記録は、権限を与えられた個人によってのみされるべきで、システムは、

 入力内容と、入力した個人、いつ入力されたかの詳細を記録しなければならない。

-データはソフトウエアで管理された特定のフォーマットで入力されていなければなら

 ない。

 バリデーション活動では、正しくないデータ・フォーマットはシステムに受け入れら

 れないことを確認すべきである。

-全ての重要データの手動入力は、第二のオペレータ、または、バリデートされたコン

 ピュータ化された手段により、確認されるべきである。

-入力の変更は監査証跡に保存され、適切に権限を与えられ独立した職員によりレビュ

 されるべきである。

〇自動入力の場合(9.3章の表も参照)：

-データの発生元であるシステムとデータの保存と記録をするシステムの間のインタ

 フェースは、データの正確性を保証するためにバリデートされるべきである。

-システムによって保存されたデータは、改ざん、喪失、変更に対して脆弱でない

 フォーマットでメモリに保存されるべきである。

-システムのソフトウエアは、保存されたデータと、データに関連する全てのメタデータ

 の完全性を保証するために、バリデートされたチェックを組み込むべきである。

■１－期待を満たさない場合の潜在的なリスク/チェック項目

・コンピュータ化システムに手動でされた入力は、適切な第二のチェックを行うことを

  保証せよ。

・自動のデータ保存を使用しているシステムに関するバリデーションの記録は、データの

　検証とインテグリティの方法が実装され、効果的であることを保証するためにレビュ

　されるべきである。例：自動保存機能がバリデートされ、ユーザにはそれを無効にし、

　報告されていないデータを生成することができないことを検証せよ。

――――――――――――――――――――――――――――――――――――――――

■２－期待

データへの必要な変更はすべて、承認された手順に従って、承認され、管理されなければ

ならない。

たとえば、試験結果の手動の積分や再加工は、承認され、管理された方法で実施されな

ければならない。会社の品質部門は、必要な時に指名された人によってのみデータへの

変更が実施されることを保証するための手順を制定しなければならない。オリジナルの

（変更されていない）データは、そのオリジナルの形式で保存されなければならない。

ローデータに対するすべての変更や修正は、完全に文書化され、少なくとも一人の適切に

訓練され、適格な個人によりレビュされ承認されなければならない。

■２－期待を満たさない場合の潜在的なリスク/チェック項目

・データの全ての修正や再加工を管理するための適切な手順が存在することを確認せよ。

　エビデンスは、提案された変更の正式な承認、管理された/制限された/明示された

　変更、実施された変更の正式なレビュの適切なプロセスを示すべきである。

 

9.8　コンピュータ化システム内のデータのレビュ

＜電子データのレビュ＞

■１－期待

規制を受けるユーザは、コンピュータ化システムにより生成された全てのGMP/GDPに関連

する電子データを確認し、データの重要性を確認するために、リスクアセスメントを実施

しなければならない。一旦確認したら、重要なデータは、規制を受けるユーザによって

監査され、作業が正しく行われ、変更（修正、削除、上書き）が電子記録上でオリジナル

の情報に対して実施されたかどうか、また関連する報告されていないデータが生成された

かどうかを判断するために検証されなければならない。全ての変更は、正式に承認され

なければならない。

SOPは、どのデータが第二のオペレータによりチェックされるかプロセスを述べなければ

ならない。これらのSOPは、レビュされる重要なローデータ、データ・サマリのレビュ、

関連するログブックやハードコピーの記録のレビュの概要を述べ、いかにレビュが実施

され、記録され、承認されるかを説明しなければならない。

監査証跡のレビュは、承認プロセスの中の所定のデータレビュの一部でなければならない。

監査証跡のレビュの頻度、役割と責任は、コンピュータ化システムに記録されたデータ

のGMP/GDPに関連する価値によるリスクアセスメントに基づくべきである。例えば、

医薬品の品質に直接の影響を持つ電子データの変更に関しては、重大な決定（例：出荷

判定）をするのに利用される前に、監査証跡のレビュが実施されることが期待されるだ

ろう。

規制を受けるユーザは、監査証跡をいかにレビュするか、何を探し、いかに検索するか

等の詳細を述べたSOPを制定すべきである。手順は、監査証跡のレビュを担当した職員が

従うべきプロセスを詳細に決定すべきである。監査証跡のレビュ活動は、文書化され、

記録されるべきである。

監査証跡のレビュ中にみつかった、期待される結果からのばらつきは、完全に調査され

記録されなければならない。手順には、監査証跡のレビュで、医薬品の品質やデータの

インテグリティに影響を与えうる重大な問題を確認した場合に取られるべきアクション

を記載しなければならない。

■１－期待を満たさない場合の潜在的なリスク/チェック項目

・電子データがその重要性（製品品質及び/または意思決定への影響）に基づいてレビュ

　されていることを保証するためのローカルの手順をチェックせよ。各レビュのエビデ

　ンスは記録され、査察官が利用可能でなければならない。

・データ・サマリが内部または外部の報告のために使用される場合、それらのサマリが

　ローデータと一緒に確認されたことを示すためのエビデンスが利用可能でなければ

　ならない。

・規制対象の団体は、いかに第二のレビュや監査証跡のレビュが実施され、もし一連の

　レビュ中に問題がみつかった場合、どんな手順がとられるかをまとめた詳細のSOPを

　持っていることをチェックせよ。

・グローバルなシステムが使用される場合、記録が同時に行われたことを示すために、

　タイム・ゾーンの記録を含む日時の記録が必要になるかもしれない。

・既知のデータに対する変更、修正、削除が、監査証跡機能により実際に記録されて

　いることをチェックせよ。

――――――――――――――――――――――――――――――――――――――――

■２－期待

会社の品質部門は、現在の管理の効果的な実施を保証し、潜在的なノンコンプライアンス

の問題を検知するために、監査証跡の重要性とシステムの複雑性に基づき、継続的に監査

証跡のレビュを実施するためのプログラムとスケジュールを制定すべきである。これらの

レビュは会社の自己査察プログラムの中に組み込まれていなければならない。

手順は、監査証跡の矛盾に対応し調査するために整っていなければならない。必要な場合

は経営陣や国の当局に知らせる上申プロセスも含んでいなければならない。

■２－期待を満たさない場合の潜在的なリスク/チェック項目

・自己査察プログラムは、存在している管理の効果とデータのレビュに関する内部手順

　に従っていることを確認するために、監査証跡のチェックを含んでいることを確認せよ。

・監査証跡のレビュは、ランダム（偶然に選択される）なものと、的を絞った（重大性

　やリスクに基づき選択される）ものの両方でなければならない。

 

9.9　電子データの保管、アーカイブ、廃棄

■１－期待

データの保管は、安全でバリデートされた手順を使い、監査証跡を含む完全なオリジナル

のデータと全ての関連するメタデータを含んでいなければならない。

もしデータがバックアップされたり、コピーが作られたりする場合、バックアップや

コピーも、データに対する許可されないアクセスや変更、削除、修正を禁止するための、

オリジナルの保管と同じ適切な管理レベルでなければならない。例えば、携帯用のハード

ドライブにバックアップをとる会社は、そのハードドライブからデータを削除することを

禁止しなければならない。データの保管とバックアップに関するいくつかの追加で考慮

すべきことには以下のことが含まれる：

-動的電子記録の真正なコピーは、全ての内容（すなわち、全てのデータと関連するメタ

 データが含まれる）とオリジナルの記録の意味が維持されているという期待と共に作成

 することができる。

-保管されたデータは完全に判読可能なフォーマットでアクセスできなければならない。

 データの保持期間中、電子的に保管されたデータのバックアップやコピーにアクセス

 するために、会社は、適切なソフトウエアとハードウエアを保持する必要があるかも

 しれない。

-定期的なバックアップのコピーは、災害に備えて、離れた場所（物理的に離れている）

 に保管されなければならない。

-バックアップデータはソフトウエアが新しいバージョンに更新されたり、より性能の

 よいバージョンに置き換えられたりしても、定められた法的な保持期間中はずっと、

 判読可能でなければならない。

-システムは、メタデータと監査証跡を含む全てのデータのバックアップとリストアが

 可能でなければならない。

■１－期待を満たさない場合の潜在的なリスク/チェック項目

・データのストレージ、バックアップ、アーカイブのシステムは、全てのデータと関連

  するメタデータを保存するために設計されていることをチェックせよ。これらの

　システムがバリデートされ、検証されていることを示す文書化されたエビデンスが

　なければならない。

・保存されたメタデータの範囲は、リスクマネジメントの原則に基づいていなければ

　ならない。またユーザは、活動や処理を再現するために必須の全てのメタデータが

　保存されていることを保証しなければならない。

・廃止された、またはアップグレードされたシステムに関連するデータは適切に管理

　され、アクセス可能であることをチェックせよ。

――――――――――――――――――――――――――――――――――――――――

■２－期待

記録の保持手順は、メタデータを保持する対策も含まなければいけない。これは、将来

の問合せや調査のために、ロットに関して発生した活動を復元することを可能にする。

――――――――――――――――――――――――――――――――――――――――

■３－期待

データは書かれた手順に従って定期的にアーカイブされなければならない。アーカイブ

のコピーは、バックアップとオリジナルデータが保管されている場所から隔離されて

離れた場所で物理的に（または、関連するコンピュータ上で）保護されていなければ

ならない。

アーカイブのすべての期間中、データはアクセス可能で判読可能で、そのインテグリティ

が保持されていなければならない。

調査が必要とされた場合に備えて、アーカイブデータのリストアに関する手順が存在して

いなければならない。アーカイブデータのリストア手順は、定期的に試験されなければ

ならない。

アーカイブのプロセスに関して設備が必要であれば、意図的またはうっかりした変更や

喪失からの保護を保証するために、特別な環境管理や、許可された職員のみのアクセスが

実施されなければならない。データへの長期のアクセスの状況が想定されるといっても

設備内のシステムを廃棄しなければいけない場合、手順は、アーカイブされたデータの

継続的な判読可能性を保証しなければならない。例えば、データを別のシステムに転送

する手段が制定されるかもしれない。

■３－期待を満たさない場合の潜在的なリスク/チェック項目

・ソフトウエア・アプリケーションの更新や装置の廃棄により、データへのアクセスや

　判読可能性が失われる可能性があるので、アーカイブされたデータにはリスクがある。

　会社がアーカイブされたデータにアクセスできて、アーカイブされたデータのレビュを

　可能にする必要なソフトウエアへのアクセスを保持していることを確認せよ。

・データのアーカイブに、外部やサードパーティの設備が利用される場合、これらの

　サービスプロバイダはアセスメントが必要であり、全ての責任は、品質技術契約の中に

　記録されていなければならない。

　アーカイブされた記録のインテグリティを保証するための考慮がされていることを確認

　するために、契約とアセスメントの記録をチェックせよ。

――――――――――――――――――――――――――――――――――――――――

■４－期待

コンピュータ化システムによって生成された全てのデータ（メタデータを含む）の判読

可能で意味のある記録のプリントアウトが可能でなければならない。

記録に対して変更がなされた場合、いつ、どのようにオリジナルのデータが変更されたか

を示す記録の変更がプリントアウトできなければならない。

■４－期待を満たさない場合の潜在的なリスク/チェック項目

・判読可能で完全な記録の生成に関してシステムがバリデートされたことを保証するため

　に、システムのバリデーション文書をチェックせよ。

・プリントアウトのサンプルを確認してもよい。

――――――――――――――――――――――――――――――――――――――――

■５－期待

・電子的に保管されたデータの廃棄に関するプロセスが記述された手順が整っているべき

　である。これらの手順はデータのアセスメントに関する手引きとデータの保持期間を

　提示し、また、もはや必要でないデータの廃棄の方法を記述しなければならない。

■５－期待を満たさない場合の潜在的なリスク/チェック項目

・手順が明確にデータの廃棄の条件を規定し、そのライフサイクル中に必要なデータの

　うっかりした廃棄を避けるための対策が講じられていることをチェックせよ。

 

9.10　ハイブリッドシステムの管理

■１－期待

ハイブリッドシステムは、システムの複雑さと、データの改ざんに対して潜在的に増加

する脆弱性を反映して、特別な追加の管理が必要である。この理由から、ハイブリッド

システムの使用は推奨されないし、そのようなシステムは可能であれば交換されるべきで

ある。

ハイブリッドシステムの各要素は、上に示した通り、手動とコンピュータ化システムに

関するガイダンスに従って、適格性が評価され、管理されているべきである。

システムに適用される管理方法の効果の評価、定義、証明をする場合、適切な品質リスク

マネジメントの原則に従うべきである。

システムの全ての主要な構成要素、各構成要素の機能、データ・マネジメントとインテ

グリティの管理、システムの構成要素の相互作用の方法の概要を述べたシステム全体の

詳細な記述が利用可能でなければならない。

手動と自動のシステム間のインタフェースを管理し、適切にコントロールするために、

手順と記録が利用可能でなければならない。特に以下に関連する手順を含めよ：

-手作業で生成されたデータのコンピュータ化システムへの手動の入力

-自動化されたシステムにより生成されたデータの紙の記録への転記（手動を含む）

-プリントされたデータの自動検知と、コンピュータ化システムへの転記

■１－期待を満たさない場合の潜在的なリスク/チェック項目

・ハイブリットシステムが明確に定義されて識別され、システムの各要素がバリデート

　されていることをチェックせよ。

・手動とコンピュータ化システムの間のインタフェースに対する注意が払われていなけ

　ればならない。査察官は、システム間で手動の転記が行われる場合、適切な管理と

　第二のチェックが行われることを確認すべきである。

・転記や処理の後に、オリジナルのデータは、保持されているべきである。

・ハイブリッドシステムは、一般に、コンピュータ化システムと手動のシステムの組み合

　わせからなっている。以下のことを確認するために特別な注意が払われるべきである：

〇コンピュータ化システムの適格性評価　及び/または バリデーションの範囲

〇手動のプロセスの一貫した適用の難しさによる、ハイブリッドシステムの手動の要素の

　マネジメントに適用される管理の安定性

――――――――――――――――――――――――――――――――――――――――

■２－期待

ハイブリッドシステムにより生成されたデータのレビュを管理するために、電子と紙ベース

のデータの評価と承認に関するプロセスを明確にまとめた手順が整えられているべきで

ある。手順は以下のことをまとめているべきである：

-完全なデータを作るために、電子データと紙ベースのデータをいかに関連付けるかの指図

-各システムから出力されたデータの承認に関する期待

-管理の効果的な適用の確認に焦点をおいた、ハイブリッドシステムで明らかにされたリスク

■２－期待を満たさない場合の潜在的なリスク/チェック項目

・ハイブリッドシステムのデータのレビュに関する指図が整っていることを確認せよ。

 

 

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

まとめ

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

いかがでしたでしょうか。

あらためて、データの管理やインテグリティについて、注意を払わなければならないこと

の多さを実感しました。

 

個人的には、以下の記述が参考になりました。

・監査証跡機能が欠けているコンピュータ化システムは、要件を満たせば代替手段

　（ダブルチェック等）も可能であること。（9.6章　１）

・重要な操作については、操作完了のレビュ前（例：ロットのリリース判定前）に、

　操作に関連する他の全ての記録と一緒にレビュされなければならない。（9.6章　１）

・複数の一連作業に関し、それが、重要管理点（CCP）であれば、各作業の時間は別々に

　記録されなければいけない。また、CCP出ない場合は、一連作業が1つのタイムスタンプ

　で記録されていてもいい。（9.6章　２）

・グローバルなシステムが使用される場合、記録が同時に行われたことを示すために、

　タイム・ゾーンの記録を含む日時の記録が必要になるかもしれない。(9.8章　１)

・監査証跡のレビュは、ランダム（偶然に選択される）なものと、的を絞った（重大性や

　リスクに基づき選択される）ものの両方でなければならない(9.8章　２)

 

☆次回は、10章以降を、9/15（水）に配信させていただきます。

 

 

◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇

★弊社サービスのご案内

https://drmarketing.jp/cch/73/500/3/425/372558/a1c8e9

 

★ブログ毎日更新中！

◆ PROS.社長の滋養強壮ブログ

https://drmarketing.jp/cch/73/500/1/425/372558/2cb1ef

◆ プロス橋本のブログ

https://drmarketing.jp/cch/73/500/2/425/372558/ae1681

※URLクリック数の統計をとらせていただいております。

 

 

本メルマガは、名刺交換させていただいた方に、毎月1日、15日に配信いたしております。

今後メルマガが必要ない方は、お手数ですが下記まで配信停止依頼のメールをお願いします。

hashimoto@e-pros.co.jp

 

【発行責任者】

株式会社プロス

『ASTROM通信』担当　橋本奈央子

～安全な医薬品の安定供給をご支援する～

こんにちは

ASTROM通信担当の橋本奈央子です。

 

まだまだ残暑が厳しい毎日ですが、いかがお過ごしでいらっしゃいますか？

 

今回も前回に引き続き、2021年7月1日に発効したPIC/Sガイドライン、

「GMP/GDP環境でのデータ管理とインテグリティに関する適正管理基準（PI 041-1」

について見ていきたいと思います。

 

出典

https://picscheme.org/docview/4234

 

 

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

PIC/S　GUIDANCE

GOOD PRACTICES FOR DATA MANAGEMENT AND INTEGRITY IN REGULATED GMP/GDP ENVIRONMENTS

 

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

９章　コンピュータ化システムに関するデータ・インテグリティの留意事項 

9.1　医薬品品質システムの体制とコンピュータ化システムの管理

9.1.1 多種多様なコンピュータ化システムが多数の操作を手助けするために会社で

　　　使用されている。シンプルなスタンドアロンから、広く統合されて複雑なもの

　　　まであり、それらの多くは、製造される製品の品質に影響を与える。全ての

　　　コンピュータ化システムを評価して管理し、GMP及びGDPの要件に従って運営

　　　することは、法律で規制された組織の責任である。

9.1.2 組織は、利用されるコンピュータ化システムの性質と範囲を完全に承知している

　　　べきであり、各システムの使用目的と機能、改ざんの影響を受けやすい

　　　データ・インテグリティのリスクまたは脆弱性の記述のアセスメントが行われて

　　　いるべきである。製品品質に関わるコンピュータ化システム及び関連するデータ

　　　の重要性の判断に重点が置かれるべきである。

9.1.3 製品品質に影響を与える可能性のある全てのコンピュータ化システムは、偶然

      または意図的な改ざん、または、データの品質やインテグリティに影響を与えうる

　　　変更やその他の活動からシステムが保護されていることを保証するために設計

　　　された医薬品品質システムのもとで効果的に管理されるべきである。

9.1.4 規制対象のユーザはシステムのベンダがGMP/GDPとデータ・インテグリティの

　　　要件の適切な理解を持つことと、新しいシステムが効果的なデータ・マネジメント

　　　を保証するための適切な管理を含むことを保証しなければいけない。

　　　レガシー・システムも、同じ基本要件を満たすことが期待されるが、完全な

　　　要件遵守には、管理上の手順またはセキュリティを補うハードウエア/ソフトウエア

　　　のような追加の管理の使用を必要かもしれない。

9.1.5 規制対象のユーザは、コンピュータ化システムで生成されるデータの範囲と性質を

　　　完全に理解すべきである、データのリスクとデータ（メタデータを含む）の重要性

　　　を判断し、生成されたデータを管理するために必要とされるその後の管理に、

　　　リスクベースドアプローチがとられるべきである。例えば：

9.1.5.1 ローデータに対処する際、製造のイベントや分析を復元するために、ローデータ

　　　　の完全な保存と保持が標準的に必要とされなければならない。

9.1.5.2 メタデータに対処する際、一部のメタデータはイベント（例：ユーザの識別、

　　　　時間、重要な工程のパラメータ、測定の単位）の復元に重要であり、“関連する

　　　　メタデータ”として、完全に保存され管理されるべきである。しかし、システムの

　　　　エラーログやシステムチェックのような重要でないメタデータは、

　　　　リスクマネジメントの使用が正当である根拠がある場合、全ての保存と管理は

　　　　必要でないかもしれない。

9.1.6 データの脆弱性やリスクを判断するとき、コンピュータ化システムの

　　　ビジネスプロセス内での使用の背景が考慮されることが重要である。例えば、

　　　統合されたコンピュータのインタフェースを利用した分析手段により生成された

　　　結果のインテグリティは、サンプルの準備、システムへのサンプルの重さの入力、

　　　データを生成するためのシステムの利用、データを使用した最終結果の処理・記録

　　　の影響を受ける。データフローマップの作成とアセスメントは、特に連携した

　　　コンピュータ化システムのリスクと脆弱性の理解に役立つだろう。

9.1.7 特に今のデータ管理の要件を満たすために設計されている現代的なシステムを

　　　利用するより脆弱なシステム及び/またはソフトウエアには、固有のデータ・インテ

　　　グリティの管理が組み入れられることが考慮されるべきである。脆弱性を持つ

　　　システムの例：マニュアルの記録システム、時代遅れのセキュリティ手段を持つ

　　　より古い電子システム、ネットワーク化されていない電子システム、ネットワーク

　　　の追加のセキュリティ保護（例：ファイアウォールを使用し、不法な侵入の検知と

　　　予防をするシステム）を必要とする電子システム

9.1.8 コンピュータ化システムの査察において、査察官はアセスメント中、その会社の

　　　助言を利用することが推奨される。アクセスと指示を円滑に進めるために、会社の

　　　担当者に質問をし、指示をすることは、システムの査察を助けることができる。

9.1.9 このガイドラインは、コンピュータ化システムを背景としたデータ・インテグリティ

　　　に関する留意事項を提供することを目的としている。コンピュータ化システムに

　　　関する適正な管理基準に関する更なるガイドラインは、

　　　PIC/Sの、規制された“GxP”環境におけるコンピュータ化システムの適正な

　　　管理基準(PI 011)にも記載されているかもしれない。

9.1.10 この原則は、コンピュータ化システムの提供が外部委託されている状況でも同様

　　　 に適用する。その場合、外部委託されたサービスが、GMP/GDPの要件に従って管理

　　　 両組織に理解され効果的に実施されていることを保証するための責任は、規制を

　　　 受ける企業にある。

 

9.2　コンピュータ化システムの適格性評価とバリデーション

9.2.1 コンピュータ化システムの適格性評価とバリデーションは、関連するGMP/GDPの

      ガイドラインに従って実施されるべきである：以下の表に、コンピュータ化システム　　

　　　の適正なデータ・ガバナンスの基準の保証についての特別な期待に関する説明を

　　　提供している。

9.2.2 バリデーションだけでは、生成された記録が適切に保護されていることを必ずしも

　　　保証しないし、バリデートされたシステムは、偶然または悪意のある方法による

　　　喪失や変更に対して脆弱な可能性がある。従って、バリデーションは、適切な管理上

　　　のまたは物理的なコントロールや、ユーザの訓練や教育により補われるべきである。

 

9.3　バリデーションとメンテナンス

＜システムのバリデーションとメンテナンス＞

■１－期待

規制を受ける会社は、データ・マネジメントとインテグリティに関する要件が

システム調達の最初の段階と、システムとデータのライフサイクルを通じて考慮されている

ことを保証するために、適切な管理を文書化して実装しなければならない。規制を受ける

ユーザについては、機能仕様書（FS）、ユーザ要求仕様書（URS）は、データ・マネジメント

とインテグリティの要件に適切に対処しなければならない。

システムがデータ・インテグリティのコントロールに関して購入前に適切に評価されること

を保証するために、GMP/GDPの重要な装置の購入に特別な注意が払わなければならない。

使用中のレガシー・システムは、存在しているシステムの機器構成や機能が、適正なデータ・

マネジメントとインテグリティの管理基準に従って、データの適切な管理が可能なのかどうか

を判断するために評価されるべきである。これらのシステムの機能や設計が適切な管理レベル

を提供しない場合、追加の管理が検討され実装されるべきである。

■１－期待を満たさない場合の潜在的なリスク/チェック項目

・DI(データ・インテグリティ）　の要件の不十分な検討により、求められるデータ・

　マネジメントとインテグリティの期待を満たす基本機能を含まないソフトウエアシステム

　を購入することになるかもしれない。

・査察官は、新しいシステムの実装が、DIの原則を適切に考慮した手順に従っていることを

　確認しなければならない。

・いくつかのレガシー・システムは検知の可能性の低いデータの改ざんの余地があり、

　データ・マネジメントに関する適切な管理を含まないかもしれない。

・存在するシステムのアセスメントは、入手可能であり、全ての脆弱性に関する概説と、

　データ・インテグリティを保証するために実装された全ての追加の管理のリストを提供

　しなければならない。追加の管理はバリデートされていなければならず、以下のことを

　含んでいてもよい。

　〇ユーザの特権をコントロールするための管理を含まないソフトウエアの場合、

　　オペレーティング・システムの機能の使用

　　（例：Windowsのアクティブ・ディレクトリ・グループ）

　〇ソフトウエアでデータファイルの修正/削除の管理ができない場合、ファイルの

　　修正/削除を防ぐためのファイル/フォルダに対して許可をする設定操作システム

　〇生成されたデータの管理をするためのハイブリッドまたはマニュアルの仕組みの実装

――――――――――――――――――――――――――――――――――――――――

■２－期待

規制を受けるユーザは、使用中の全てのコンピュータ化システムの台帳を持っていなければ

ならない。このリストには以下のことに関する内容を含まなければならない。

-各コンピュータ化システムの名前、設置場所と主要な機能

-機能とシステム及び関連するデータの重要性のアセスメント（例：GMP/GDPへの直接の影響

 あり、非直接の影響あり、何もなし）

-各システムの現在のバリデーションの状態と、存在するバリデーション文書の参照

特に、データ・インテグリティを保証するために必要な管理の評価を行い、各システムの

リスクアセスメントが行われているべきである。データ・インテグリティに関する管理の

バリデーションのレベルと範囲はシステム及び処理の重要性と、製品品質へのリスクの

可能性に基づいて判断されるべきである。例：ロットのリリースデータを生成または管理

する処理やシステムは、一般的に、重要性の低いデータや処理を管理するシステムより

大きな管理が要求される。

より高いリスクの可能性を持つこれらのシステムについて、災害、誤動作、または、

システムが動作不能になることに関する考慮もされるべきである。

アセスメントは、システムの重要な構成設定の不注意もしくは無断の変更や、データの

改ざんに関する脆弱性もレビュすべきである。全ての管理は、文書化され、有効性が

検証されていなければならない。

■２－期待を満たさない場合の潜在的なリスク/チェック項目

・全てのコンピュータ化システムに関して適切な可視性を持たない会社はシステムの重大性

　を見落とし、データのライフサイクルを通じて脆弱性を生むかもしれない。

・システム台帳は、これらのシステムに対するすべての変更や改良が管理されることを

　保証し、全てのシステムが明確に連携することに役立つ。

・リスクアセスメントが重要な処理装置やデータ収集システムに関して実施されている

　ことを確認せよ。システムの影響の徹底的なアセスメントの欠如は、適切な

　バリデーションとシステムの管理の欠如につながるだろう。レビュするための重要な

　システムの例は、以下の通りである。

  -製品及び原材料の購入やステイタスの管理をするシステム

　-重要な製造工程の管理とデータ収集をするシステム

　-ロットの品質を判断するために使用される、データを生成し、保存し、処理する

　 システム

　-ロットの加工や包装の記録に含まれるデータを生成するシステム

　-製品の出荷判定に関する判断の過程で使用されるシステム

――――――――――――――――――――――――――――――――――――――――

■３－期待

各コンピュータ化システムのバリデーション・サマリ・レポート（Annex15の要件に

従って書かれ承認されたもの）が整えられ、少なくとも下記の内容が記述（もしくは

参照）されていなければならない。

-重要なシステムの構成設定の詳細と、構成設定へのアクセス制限に関する管理と、

 全ての変更（変更管理）

-ユーザの名前とその役割を明記した、現在許可されている全ての通常のユーザと

 管理ユーザのリスト

-監査証跡とシステムログのレビュの頻度

-下記の手順

　○新しいシステムユーザの作成

　○存在しているユーザの修正または権限の変更の手順

　○各システムのパスワードの組み合わせ/フォーマットの定義

　○ユーザのレビュと削除の手順

　○バックアップの手順と頻度

　○災害復旧

　○アーカイブしたデータのアクセスと読み取りの手順を含む、データのアーカイブ

　　（手順と責任）

　○データ保管の認められた場所

-レポートは、製造工程または分析作業を復元することを可能にするフォームで

 関連メタデータと共にオリジナルデータがいかに保管されているかを説明しなければ

 ならない。

バリデーション・サマリ・レポートには必要性が書かれていないが、既存のシステム

について、上記の要件を明記した文書が利用できなければならない。これらの文書は、

規制を受けるユーザにより、必要に応じて維持・更新されなければならない。

■３－期待を満たさない場合の潜在的なリスク/チェック項目

・バリデーションのシステムとレポートが以下のGMP/GDP要件とALCOAの原則を考慮した

　インテグリティの要件に対応していることをチェックせよ。

・システムの構成設定と職務の分離（例：データを生成する権限は、データを検証する

　権限と独立すべきである）がバリデーションの前に定義され、試験中効果的に検証

　されているべきである。

・システムへの改良や変更が制限され、変更管理マネジメントの対象になっていること

　を保証するためのシステムのアクセスに関する手順をチェックせよ。

・システムの管理者アクセスがオーソライズド・パーソンに限定されていて、日常の

　作業で使用されていないことを保証せよ。

　保証するために、その手順をチェックせよ。ユーザのアクセスログと特権レベルを

　チェックせよ。権限のないユーザのシステムへのアクセスがなく、アクセス・アカウント

　は最新化されていなければならない。

・ユーザが監査証跡機能を修正することや、予め設定されたデータファイルが保存される

　ディレクトリ・パスを変更することを防ぐための制限もあるべきである。

――――――――――――――――――――――――――――――――――――――――

■４－期待

会社は、コンピュータ化システムのバリデーションに関する具体的な方針と要求事項と

システムや関連データのインテグリティの要求事項を含むバリデーション・マスタ・プラン

を整えなければいけない。

コンピュータ化システムのバリデーションの範囲は、リスクに基づいて判断されなければ

ならない。

コンピュータ化システムバリデーションの要求事項の評価に関する更なるガイドラインは、

PI 011にも記載されているだろう。

システムが日常的な使用に移行する前に、許容範囲に適合することを確認するために

決められたテストが実施されなければならない。

コンピュータ化システムの予測的バリデーションが実施されることが期待される。適切な

バリデーションデータが、既に使用中のシステムにおいて利用可能でなければならない。

コンピュータシステムバリデーションは、必要に応じて、GMP Annex15のURS（ユーザ

要求仕様書）、DQ（設計時適格性評価）、FAT（工場出荷試験）、SAT（現地受入試験）、

IQ（据付時適格性評価）、OQ（運転時適格性評価）、PQ（性能適格性評価）の内容に

従って設計されなければならない。

適格性評価の試験のアプローチは、バリデーション中、具体的なシステムに関して調整

され、規制を受けるユーザによって正当である根拠が示されなければならない。適格性

評価には、DQ（設計時適格性評価）、IQ（据付時適格性評価）、OQ（運転時適格性評価）、

PQ（性能適格性評価）を含む。特に、データの品質やインテグリティにリスクがある

分野の試験をするために、固有の試験が計画されるべきである。

会社は、コンピュータ化システムがその使用目的に関して適格性が評価されていること

を保証すべきである。従って、会社は、ベンダの適格性評価されたパッケージだけを

信頼すべきではない；バリデーション活動は、通常の使用と意図した使用が織り込ま

れた作業中にデータのインテグリティが維持されることを保証するため、特定の試験

を含むべきである。

試験の数は、リスクアセスメントにより導き出され、少なくとも重要な機能が特定

されて試験されるべきである。例えば、基本的なアルゴリズムまたはロジックの

組み合わせに基づくPLCやシステムの場合は、機能的試験が、コンピュータ化システム

の信頼性を適切に保証するだろう。重要で、かつ/または、より複雑なシステムは、

IQ、OQ,PQの段階において詳細の検証試験が必要とされる。

■４－期待を満たさない場合の潜在的なリスク/チェック項目

・バリデーション文書がデータ・インテグリティに関する固有の条項を含んでいる

　ことを確認せよ；バリデーション・レポートは、データ・インテグリティの原則に

　対応し、設計と試験を通じて適切な管理が整っていることを示すべきである。

・バリデートされていないシステムは、ユーザのアクセスやシステム設定がデータ

　の修正を許す可能性があるので、データ・インテグリティに関して重大な脆弱性

　が存在するかもしれない。

・エンド・ユーザの試験は、ソフトウエアがベンダの要件を満たすだけでなく、その

　意図した使用に合っていることを示すために設計されたテストスクリプトを含んで

　いることをチェックせよ。

――――――――――――――――――――――――――――――――――――――――

■５－期待

定期的なシステム評価

コンピュータ化システムは、データ・インテグリティの管理を考慮した継続的な

コンプライアンス状態にあることを保証するために定期的に評価されるべきである。

評価は、逸脱、変更（変更の全ての蓄積された影響を含む）、アップグレードの

履歴、性能とメンテナンスを含むべきである。また、これらの変更がデータ・

マネジメントとインテグリティの管理に有害な影響を与えなかったかを評価すべき

である。

再バリデーションの頻度は、前回のレビュからシステムに対して実施された変更の蓄積

された影響を考慮し、コンピュータ化システムの重要性によるリスクアセスメントに

基づくべきである。実施されたアセスメントは文書化されるべきである。

■５－期待を満たさない場合の潜在的なリスク/チェック項目

・バリデーション・スケジュールの中に、コンピュータ化システムの再バリデーション

　のレビュの概要が述べられていることをチェックせよ。

・システムが、特にデータ・インテグリティに関する全ての潜在的な脆弱性を考慮し、

　定期的なレビュの対象になっていることを確認せよ。

・既存のソフトウエア/ハードウエアの欠点などの、確認された全ての問題がタイムリー

　に対処され、確認された全てのリスクを管理するために是正処置・予防処置や暫定的

　な管理が利用可能で実施されるべきである。

――――――――――――――――――――――――――――――――――――――――

■６－期待

オペレーティング・システムとネットワーク部品(ハードウエアを含む)はベンダの提案

に従ってタイムリーに更新され、古いプラットフォームから新しいプラットフォームへ

のアプリケーションの移行は、システムにより生成されたデータのマネジメントと

インテグリティに影響を与えうることになるプラットフォームがサポートされない状態

になる前に計画され、実行されるべきである。

オペレーティング・システムとネットワーク部品のセキュリティ・パッチは、データの

安全性を維持するために、ベンダの提案に従って、管理されたタイムリーな方法で適用

されるべきである。セキュリティ・パッチの適用は、変更管理の原則に従って実施される

べきである。

サポートされていないオペレーティング・システムが維持される場合、即ち、古い

オペレーティング・システムについて、ベンダもしくはサポートされたバージョンの

セキュリティのパッチがあてられる期間が切れた後は、システム（サーバ）は、可能な

限り、その他のネットワークから隔離されるべきである。残ったインタフェースと他の

装置へ/からのデータの転送は、サポートされていないオペレーティング・システムに

より引き起こされる脆弱性の発生を防ぐために慎重に設計され、設定され、適格性を

評価されなければならない。サポートがされていなシステムは、固有の脆弱性のリスク

により、リモートアクセスは慎重に評価されるべきである。

■６－期待を満たさない場合の潜在的なリスク/チェック項目

・システムのアップデートは、管理されたタイムリーな方法で実施されていることを

　確認せよ。古いシステムは、適切なデータ・インテグリティの管理が統一されている

　こと、または、（統一した管理が不可能な場合は）適切な管理が実装されていて効果的

　であることが十分にレビュされるべきである。

 

9.4　データ転送

＜データ転送と移行＞

■１－期待

インタフェースは、正しく完全なデータの転送を保証するために、バリデーション中に

評価され対処されるべきである。

インタフェースは、データ・インテグリティのリスクを最小化するために、正しい安全な

データの入力と処理に関する適切な組み込みのチェックを含むべきである。検証方法は、

下記の使用を含むとよい。

○安全な転送

○暗号化

○チェック・サム（※データ通信におけるエラー検出方法の一つ）

可能であれば、システム間のインタフェースは、GMP/GQPデータの転送の自動化を含めて

設計され、検証されるべきである。

■１－期待を満たさない場合の潜在的なリスク/チェック項目

・コンピュータ化システム間のインタフェースは、転送中に、データが気づかずに失われ

　たり、間違って修正されたり書き換えられたりするリスクをもたらす。

・データが安全な場所/データベースに直接転送され、ローカル・ドライブ（変更される

　可能性がある場所）から簡単にコピーされないことを保証せよ。

・最終的なデータ保管場所またはデータ処理場所に転送される前のローカルな

　コンピュータ化システム（例：機器のコンピュータ）の一時的なデータ保管場所は、

　データが消されたり、改ざんされたりする可能性を作る。これは、スタンドアロン

　（ネットワークでつながっていない）システムの固有のリスクである。最初にデータ

　が保管された環境は適切なデータ・インテグリティの管理が整っていることを保証せよ。

・うまく設計され、適格性評価がされている自動データ転送は、人により実施される

　いかなる手動データ転送より信頼できる。

――――――――――――――――――――――――――――――――――――――――

■２－期待

システムのソフトウエア(オペレーティングシステムを含む)がインストールもしくは

アップデートされる場合、ユーザは、アーカイブされたデータが新しいソフトウエアで

読めることを保証すべきである。これは、必要に応じて、存在しているアーカイブされた

データの新しいフォーマットへの変換が求められるかもしれない。

データが新しいソフトウエアの新しいデータ・フォーマットに変換が出来ない場合、

古いソフトウエアは、例えば１つのコンピュータ内にインストールされるか、他の技術的

解決策により維持され、査察時にアーカイブされたデータを読むために

バックアップメディアとして利用可能でなければならない。

■２－期待を満たさない場合の潜在的なリスク/チェック項目

・データのライフサイクルを通じて、データはそのもともとの形式で読めることが重要で

　ある。従って、ユーザは、データの可読性を維持しなければならず、廃止されたソフト

　ウエアへのアクセスを保持することが求められるかもしれない。

・1つのシステムから別のシステムへのデータの移行は、管理された方法で、文書化手順

　に従って実施され、データの完全な移行の適切な検証を含まなければいけない。

――――――――――――――――――――――――――――――――――――――――

■３－期待

レガシー・システムのソフトウエアがもはやサポートされない場合、データのアクセス可能性

 (特定の保管要件によりできるだけ長く))のために、ソフトウエアの維持に関して考慮される

べきである。これは仮想環境にソフトウエアを保持することで達成されるかもしれない。

可能な限り“真正なコピー”の属性をもった他のファイルフォーマットへの移行は、年数が

経過するレガシー・データに必要になるかもしれない。

オリジナルのデータの機能完全に備えた移行が技術的に可能でない場合、代替手段が、リスク

とデータの重要性に基づいて時間と共に評価されるべきである。移行ファイルフォーマット

は、長期間のアクセス可能性 対 動的データの機能(例：データの問い合わせ、トレンド、

再加工)の減少の可能性を考慮して選択されるべきである。リスクアセスメントは、システム

の重要な構成設定へのうっかりした、または、許可されない変更や、データの改竄に対する

脆弱性のレビュもすべきである。リスクを軽減するための全ての管理は文書化され、それら

の有効性が検証されるべきである。アクセス可能性を維持するために、いくつかの属性・

動的データの機能を失うファイルフォーマットへの移行を必要とするかもしれないことは

受け入れられる。

■３－期待を満たさない場合の潜在的なリスク/チェック項目

・ソフトウエアが仮想環境に保持される場合、ソフトウエアを管理するための適切な手段

　（例：バリデーション状態、許可された職員によるアクセス管理）が整っていることを

　チェックせよ。全ての管理は文書化され、それらの有効性が検証されるべきである。

 

9.5　コンピュータ化システムのシステム・セキュリティ

＜システム・セキュリティ＞

■１－期待

ユーザのアクセス管理は、データへの権限のないアクセスや変更や削除を禁止するために

設定され、強化されなければならない。セキュリティ管理の範囲は、コンピュータ化

システムの重要性による。例えば：

-個々のログインIDとパスワードは、電子システムにアクセスし利用する必要のある全て

 のスタッフに設定され、与えられなければならない。共有されたログイン認証情報は、

 活動を行った個々のトレーサビリティのために、許されない。この理由から、経済的な

 節約のためであっても、共有パスワードは禁止されるべきである。

 ログイン・プロファイル、構成設定、パスワードのフォーマットが明確に定義され、

 意図した通りに機能することを保証するために、電子システムのバリデーション中に

 検証されるべきである。

-コンピュータ化された記録に対するデータの入力と変更は、許可された職員によって

 のみ実施されるべきである。会社は、使用中の各電子システムについて、アクセスを

 許可された個人と、彼らのアクセス権限のリストを保持すべきである。

-システムが効果的に保護されていることを保証するために、パスワードのフォーマット

 と使用に関する適切な管理が行われるべきである。

-はじめに許可されたシステムのアクセスに基づき、システムは、通常のパスワードの

 ルールに従い、ユーザが新しいパスワードを作ることを許可しなければならない。

-システムは、ユーザのさまざまなアクセスの役割（レベル）をサポートし、役割の

 割り当ては、最低限の特権付与のルール、すなわち、いかなるジョブの機能に

 対しても最低限必要なアクセスレベルを付与すること、に従うべきである。最低限

 として、シンプルなシステムは、通常ユーザと管理ユーザを持つべきだが、より複雑

 なシステムは、通常は、アクセス管理を効果的にサポートするためにユーザにより

 多くのレベル(例：階層)が必要になるだろう。

-GMP/GQPの重要なアプリケーションを運営するために、コンピュータシステムや

 インフラへの管理者のアクセス権限を許可することは、厳しく管理されるべきである。

 管理者のアクセス権限は、システムの通常のユーザに与えられるべきではない。

 （職務の分離）

-通常のユーザは、コンピュータシステムの重要な局面へのアクセス権限を持つべきで

 ない。（例：システム・クロック、ファイルの削除機能等）

-システムは、システムに実際にアクセスしたユーザの名前と役割を含むリストを作る

 ことができるべきである。そのリストは、定期的なユーザのレビュ中に用いられる

 べきである。ユーザのリストは、名前または特定の個人を識別できるユニークな識別子

 を含むべきである。このリストは、定期的なユーザのレビュ中に使用されるべきである。

-システムは、下記の情報を含んだ、ログインの試みの成功と失敗のリストを作ることが

 できるべきである。

 ○ユーザの名前

 ○ユーザの役割

 ○ログインを試みたローカル時間、または、ローカル時間がトレースできる日時

 ○セッション(交信)の長さ（ログイン成功時）

-ユーザのアクセス管理は、役割の厳格な分離を確実に行うべきである。（すなわち、

 通常の業務を行うシステムの全ユーザは、通常のアクセス権限のみを持つべきである。)

 普通は、高いアクセス権限を持ったユーザ（例：管理者）は、システムで通常業務を

 実施すべきでない。

-システム管理者は、通常、ユーザの実施する業務と独立し、生成されたデータに関与

 や関心を持ってはいけないし、電子システムを利用できてはいけない。例えば、QCの

 管理者やマネージャは、試験室の電子システム（例：HPLC、GC、UV－Vis）の

 システム管理者に任命されるべきではない。通常は、品質や製造の組織の外部の人間

 （例：情報技術の管理者）がシステム管理者の役目を果たし、高度な許可レベルを

 持つべきである。

-より小さな組織の場合、品質部門や製造部門で指名された人間がシステム管理者として

 アクセス権限を持つことは許容してもよい。しかし、これらの場合、管理者のアクセス

 は、日常作業の実施に用いられるべきではなく、ユーザは、第二の日常作業の実施用の

 制限されたアクセス権限を持つべきである。これらの場合、管理者の実施した全ての

 活動は、記録され、品質システム内で承認されるべきである。

-新しいユーザ、新しいユーザの権限に関する全ての要求は、適切な職員（例：ライン

 のマネージャ、システムオーナ）に許可され、標準手順に従ってトレース可能な

 方法でシステム管理者に送付されなければならない。

-GMP/GQPの重要なデータや作業にアクセスするコンピュータシステムは、事前に定義

 した時間よりも長い間不応のユーザを、アプリケーションまたはオペレーション・

 システムレベルでログアウトする非活動ログアウト機能を持つべきである。その時間

 は、通常は、長くするのではなく、システムへの権限のないアクセスを防ぐために

 短く設定されるべきである。非活動ログアウトの有効化に加え、システムは、

 再ログインのために通常の認証手順を要求すべきである。

■１－期待を満たさない場合の潜在的なリスク/チェック項目

・会社が、使用中のコンピュータ化システムが安全で、意図的またはうっかりした変更

  から保護されていることを保証するためにあらゆる合理的なステップを踏んでいる

　ことをチェックせよ。

・物理的かつ管理上保護されていないシステムは、データ・インテグリティの点で脆弱

　である。査察官は、コンピュータ化システムがバリデートされ、改ざんから保護

　された状態が保たれていることを保証する、システムのセキュリティを管理する検証

　された手順が存在することを確認すべきである。

・個々のユーザログインIDが使用されていることを確認せよ。システムの構成設定が、

　個々のユーザのログインIDの使用を認めている場合、これらが使用されるべきである。

・一部のコンピュータ化システムは、単一ユーザのログイン、または、限定された人数

　のユーザのログインのみをサポートしていることが認識されている。適切な代替の

　コンピュータ化システムが利用できない場合、サードパーティのソフトウエア、

　または、トレーサビリティ（バージョン管理と共に）を提供する紙ベースの方法に

　よる同等の管理が提供されてもよい。代替システムの適合性は、正当化され、文書化

　されなければならない。ハイブリッドシステムについては、さらなるデータレビュが

　求められることがありうる。

・査察官は、システムが適切なパスワードのルールを強制し、強固なパスワードを要求

　することを保証するためにパスワードの方針が整っていることを確認すべきである。

　重要なデータを生成し処理するシステムには、より強固なパスワードを使用するため

　の検討がなされるべきである。

・ユーザによって新しいパスワードが変更できず、管理者のみがパスワードを作れる

　システムは、パスワードの信頼性が保持できないので、データ・インテグリティに

　合わない。

・ユーザのアクセスレベルが適切に定義され、文書化され、管理されていることを

　チェックせよ。ユーザの単一のアクセスレベルを使用し、この役割を全ユーザに

　割り当てることは、定義次第でアクセスレベルは管理者の権限になるので、

　容認できない。

・許可された個人だけがシステムを使用でき、電子的に記録に署名し、操作を行い、

　入力または出力装置にアクセスし、記録を変更し、または手近で作業が行えること

　を保証するために、システムは管理者がチェックしていることを確認せよ。

――――――――――――――――――――――――――――――――――――――――

■２－期待

コンピュータ化システムは、偶然の変更や意図的な改ざんから保護されているべきで

ある。会社は、最終的にデータ・インテグリティに影響を与えうるバリデートされた

設定に対する許可のない変更を防ぐためにシステムとその設計を評価すべきである。

以下の考慮がされるべきである。

-コンピュータ化システムのハードウエアの物理的セキュリティ：

 〇サーバの場所とアクセス制限

 〇PLCモジュールへのアクセス制限（例：点検用パネルの錠締め）

 〇コンピュータ、サーバ、メディアへの物理的なアクセスは、許可された個人に限定

   されるべきである。通常は、システムのユーザは、サーバやメディアに対する

   アクセス権限を持つべきでない。

-ローカルや外部の攻撃からのネットワークシステムの脆弱性

-リモートのネットワークの更新（例：ベンダによるネットワークシステムの自動更新）

-システムの設定、構成や重要データのセキュリティ

 システムの重要なデータ/操作パラメータへのアクセス権限は適切に制限され、

 設定/構成の変更は、権限を与えられた職員により変更マネジメント手順を通じて管理

 されていなければならない。

-システム時間は、接続するシステムの時計と同期され、全ての時計へのアクセスは

 権限を与えられた職員に限定されるべきである。

-侵入の防止と検知のシステムを含む、適切なネットワークのセキュリティの手段が

 適用されるべきである。

-ファイアウォールは、重要なデータや作業を守るためにセットアップされていな

 ければならない。ポートの開放(ファイアウォールのルール)は、可能な限り厳しくし、

 許可されたトラフィックのみを許可し、最低限の特権付与方針に基づくべきである。

 規制を受けるユーザは、ネットワークセキュリティの手段（例：潜在的なセキュリティ

 の弱さを特定するためのITインフラのネットワークの脆弱性のスキャンの使用）の

 継続的な妥当性と効果の定期的なレビュを実施し、オペレーティング・システムが

 現在のセキュリティ手段を維持していることを保証しなければならない。

■２－期待を満たさない場合の潜在的なリスク/チェック項目

・ハードウエアとソフトウエアへのアクセスが適切に保護され、権限を与えられた職員

  に限定されていることをチェックせよ。

・適切な認証方法が実装されていることを確認せよ。これらの方法は、ユーザIDと

  パスワードを含んでいるか、他の方法でもよいが、認証が要求されなければならない。

　ユーザが確実に特定可能であることが必須である。

・インターネット経由で利用できる重要なデータを含むシステムのリモートの認証に

　ついては、パスコード・トークンや生体認証の使用などの追加の認証技術が使用

　されていることを確認せよ。

・システムの重要な操作パラメータへのアクセスが適切に管理され、システムが、

　GMP/GQPの手順において、イベントやパラメータやの正しい順番を強制することを

　確認せよ。

――――――――――――――――――――――――――――――――――――――――

■３－期待

ネットワークの保護

ネットワークシステムのセキュリティは、データへの潜在的な脅威を検知し防ぐための

適切な方法を含むべきである。

実装されるネットワークの保護のレベルは、データのリスクのアセスメントに基づくべき

である。

ファイアウォールが、許可されないアクセスに使用されるべきであり、ファイアウォール

のルールは、許可されたトラフィックのみ許可し、必要であれば制限をかけるように設定

されていることを保証するために、定期的なレビュの対象とされるべきである。レビュは

文書化されていなければならない。

ファイアウォールは、意図的な攻撃やマルウェアからデータやコンピュータ化システムを

守るために、適切なウイルス保護または侵入の防止/検知システムと共に補完されなければ

ならない。

■３－期待を満たさない場合の潜在的なリスク/チェック項目

・不十分なネットワークのセキュリティは権限のないアクセスや誤用や修正による

　システムの脆弱性に関連したリスクをもたらす。

・ネットワークのアクセスを管理するための適切な方法が整えられていることを確認せよ。

　許可、モニタリング、アクセスの除去に関するプロセスが整っているべきである。

・システムは、脅威を防ぎ、ネットワークへの意図的な侵入を検知するように設計され、

　それらの手段がインストールされ、モニタされ、維持されていなければならない。

・ファイアウォールのルールは、通常は、時間と共に変化しがちである。（例：サーバ

　のメンテナンスによるポートの一時的な開放等）　もしレビュが全くされなければ、

　ファイアウォールのルールは廃れ、望まれていないトラフィックや侵入を許すことに

　なるだろう。

――――――――――――――――――――――――――――――――――――――――

■４－期待

手書き署名の代わりに使用される電子署名は、記録に電子的に署名した職員の真正性と

トレースの可能性を保証するために適切な管理がされなければならない。

電子署名は個々の記録と永久的に結びついていなければならない。すなわち、もし、署名

された記録に後で変更がなされた場合、記録は、修正を示し、署名されていないものと

ならなければならない。

電子署名が使用される場合、電子署名は機能的に、署名がされた日時を自動的に記録しな

ければならない。

電子署名のされたフォームの使用は、より一般的になってきている。（例：会社により、

生体認証の使用はより普及

してきている。）電子署名のされたフォームの使用が促進されるべきである。

■４－期待を満たさない場合の潜在的なリスク/チェック項目

・電子署名が適切にバリデートされ、職員への交付が管理され、いつも、電子署名が個人

　にすぐに帰属可能であることをチェックせよ。

・電子署名がされた後のデータへの変更は、データが再びレビュされ、再度署名される

　までは、その電子署名は無効化されなければならない。

――――――――――――――――――――――――――――――――――――――――

■５－期待

USBデバイスの使用の制限

システム・セキュリティの理由で、コンピュータ化システムは、GMP/GQPの重要なデータ

を持つクライアントコンピュータやサーバにおける、USBメモリスティックやストレージ

デバイスの使用による脆弱性を防ぐための設定がされていなければならない。必要な場合、

ポートは、承認された目的のためだけに開放され、全てのUSBデバイスは、使用前に適切

にスキャンされなければならない。

GMP/GQPの重要なデータを持つ会社のクライアントコンピュータやサーバにおける個人用

のUSBデバイスの使用（フラッシュデバイス、カメラ、スマートホン、キーボード等）、

または、個人用コンピュータにおける会社のUSBデバイスの使用は、セキュリティ違反を

防ぐために管理されなければならない。

■５－期待を満たさない場合の潜在的なリスク/チェック項目

・オペレーティング・システムの脆弱性が知られた環境では、USBデバイスが、キーボード

　のような別の外部装置であることを装うことで、実行ファイルをスタートすることが

　できるということが特に重要である。

・USBデバイスが許可されたユーザの使用に制限するための管理が整備され、USBデバイス

　が使用される前に、USBデバイスを検査するための手段が整えられるべきである。

 

 

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

まとめ

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

今回も長くてげっそりされたと思いますが、いかがでしたでしょうか。

 

色々注意すべき記載がありましたが、個人的に注意すべきと思った点や、最近忘れて

いた点を下記にピックアップしました。参考にしていただければ幸いです。

・コンピュータ化システムの管理はリスクに応じて実施すべきであること。(9.1.5章)

・システム同士の連携のリスクや脆弱性を理解するために、データフローマップの

　作成が効果的であること。(9.1.6章)

・システムが外部委託されている場合でも、データ・マネジメントとインテグリティ

　の管理は製薬企業にあること。(9.1.10章)

・使用中の全てのコンピュータ化システムの台帳を持っていること。(9.3章 ２)

・オペレーティング・システムやネットワーク部品はベンダの提案により、タイムリー

　に更新されること。

　セキュリティ・パッチはベンダの提案により、タイムリーに適用されること。

　その際、変更管理を実施すること。(9.3章 ６)

・レガシー・システムのデータのアクセス可能性を維持するためには、仮想環境に

　ソフトを置くことも検討すべきであること。（9.4章　３）

・システム管理者は、通常業務と独立した職員が実施することが望ましいこと。

　但し、小さな組織の場合は、兼務も可能であること。その場合、日常業務用ユーザと、

　管理者用ユーザを分けるべきであること。（9.5章　１）

・ユーザが管理できないコンピュータ化システムは、要件を満たせば紙ベースの管理も

　可能であること。（9.5章　１）

 

☆次回は、9.6章以降を、9/15（水）に配信させていただきます。

 

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

無料WEBセミナのご案内

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

グループ会社（キッセイコムテック株式会社）では、RPA等を活用した業務効率の向上に

関する無料WEBセミナを開催します。

1時間程度のセミナですので、手軽にご参加いただけるかと思います。

ご興味がおありの方は、下記URLからお申込みください。

 

【セミナ】

イベント名：AI-OCR「AxisRead」/RPA「AxisRobo」/クラウドストレージ

「AxisDrive」業務改善セミナ

日程： 9月7日(火) 14：00-15：00

申込HP：https://www.kicnet.co.jp/events/event/e210720/

 

 

◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇

★弊社サービスのご案内

https://drmarketing.jp/cch/73/497/3/425/369633/0de707

 

★ブログ毎日更新中！

◆ PROS.社長の滋養強壮ブログ

https://drmarketing.jp/cch/73/497/1/425/369633/80d1b3

◆ プロス橋本のブログ

https://drmarketing.jp/cch/73/497/2/425/369633/65204a

 

 

本メルマガは、名刺交換させていただいた方に毎月1日、15日に配信いたしております。

今後このような情報が必要ない方は、お手数ですが、こちらに配信停止依頼のメールを

お願いいたします。

hashimoto@e-pros.co.jp

 

【発行責任者】

株式会社プロス

『ASTROM通信』担当　橋本奈央子ここにエントリー本文を書きます。