ASTROM通信バックナンバー

2018.03.30

【MHRA発GXPデータ・インテグリティ・ガイダンス】ASTROM通信<143号>

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

こんにちは
ASTROM通信担当の橋本奈央子です。

桜の花も、もう散り始めてしまいましたが、いかがお過ごしでいらっしゃいますか。

さて今回は、2018年3月9日にMHRA(英国医薬品庁)が発出したGXPデータ・インテグリティ・
ガイダンスについて取り上げたいと思います。

ご存知の通り、データ・インテグリティは、昨今非常に重要視されていて、2016年8月には
EMAがデータ・インテグリティに関するQ&A集を出しましたが、今回のGXPデータ・インテ
グリティ・ガイダンスは、それを踏まえたガイダンスとなります。
イギリスはEUを離脱はしますが、このガイダンスにはヨーロッパの当局のデータ・インテ
グリティに関する最新の見解がまとめられていますので、是非最後までお読みいただければ
幸いです。


◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
GXPデータ・インテグリティ・ガイダンスの概要
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
2018年3月9日、MHRA(英国医薬品庁:Medicines and Healthcare products Regulatory Agency)
より、8章、21ページからなるGXPデータ・インテグリティ・ガイダンスが発出されました。
ここでいうGXPとは、MHRAにより管理されるさまざまな実施基準(good practice)をさし、
GCP(Good Clinical Practice)、GDP(Good Distribution Practice)、
GLP(Good Laboratory Practice)、GMP(Good Manufacturing Practice)、
GPvP(Good Pharmacovigilance Practice)を対象とします。
MHRAは、ドラフト版の作成後、業界や全GXPの専門グループ等から1300件以上のコメントを受け
取り、それらを考慮し、2年をかけてこの正式版をまとめたため、読み応えのあるガイダンスに
なっています。


◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
GXPデータ・インテグリティ・ガイダンスの内容
※全訳ではありませんので、気になる部分は是非原文でご確認ください。
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
1章 背景
規制関連データの生成方法は、技術の進歩や、サプライ・チェーン及び業務の複雑化により、
発展し続けてきた。これらを支援するシステムは、紙の記録を使ったマニュアルの処理から、
完全なコンピュータ化システムの使用にまで及ぶが、規制要件の主要な目的は同じで、患者の
安全と製品の品質を保証するために、生成されたデータの質と完全性に関する信頼性を持つこと
と、活動を再構成できることにある。

2章 序文
2.1 この文書はMHRAの規制を受ける業界及び公的機関に助言を与える。
   このガイダンスは、PIC/S、WHO、OECD(GLPのガイダンス及び勧告)、
EMA(欧州医薬品庁:European Medicines Agency)のガイドラインや規制と調和している。
2.2 このガイダンスは、MHRAの査察官、パートナー、パブリックコメントを経て開発された。
2.3 ユーザは、リスクからデータを保護する場合、その作業は、その他の順守すべき優先事項
と釣り合いが取れていることを保証しなければならない。
2.4 このガイダンスの対象はGXPである。但し、医療機器は含まれない。
2.5 このガイダンスは、MHRAのデータ・インテグリティに関する立場や、データ・インテグリ
ティを達成するための最低限の期待を理解する方法とみなされるべきである。
2.6 このガイダンスは、データのリスク、重大性、ライフサイクルを含むデータ管理のリスク
ベースのアプローチを促進することを目的とする。
2.7 このガイダンスは、主にデータの完全性を対象としていて、生成されるデータの品質は対象
としていない。
2.8 このガイダンスは、適用される規制や、各GXPのガイダンス、このガイダンス内で参照して
いる文書(例:ICH Q9)と併せて読まれるべきである。
2.9 ガイダンスで用語が定義されている場合、他の定義も存在するかもしれないが、可能な限り
適切にそれらと調和している。

3章 データ・インテグリティの原則
3.1 経営陣は使用するシステムやそれらが生成するデータに関する責任を負う必要がある。
組織文化は、データがいかなる形式でも(すなわち、紙でも電子でも)、完全で、一貫して
いて、正確であることを保証しなければならない。
3.2 人、システム、設備に関する組織内の配置は、適切な作業環境を下支えするために設計され、
運用され、適応されなければならない。すなわち、データの完全性の管理が効果的に行える
正しい環境が作られなければならない。
3.3 データ・ガバナンスのポリシーは、組織の最高レベルで承認されなければならない。
3.4 組織には、データ・インテグリティのリスクに基づいた満足できる管理状態を提供する
文書化されたシステムを実装し、策定し、運用することが期待される。適切なアプローチの
例として、データ・インテグリティ・リスクアセスメント(DIRA)を実施し、そこで、データ
を作る処理またはデータが取得される処理を正確に記述し、その形式や管理が明らかにされ、
データの重要性や固有のリスクが文書化されることである。
3.5 組織は、定期的なデータチェックにおいて法的アプローチを実施することは期待されていない。
システムは適切な管理レベルで維持されなければならない。また、より広範囲のデータ・ガバ
ナンスの手段は、定期的な監査がデータ・インテグリティの不具合を検知できることを保証し
なければならない。
3.6 データの完全性を保証するための取り組みや投入される資源は、データ・インテグリティの
不具合による患者または環境へのリスクや影響に釣り合っていなければいけない。
3.7 組織は、自動化システムまたコンピュータ化システムから紙ベースのマニュアルのシステムに
立ち戻ることが、適切なデータ・インテグリティの管理の必要性を取り除くものではないことを
認識しなければならない。
3.8 データ・インテグリティの欠点が明らかになったら、企業は、全ての関連する活動または
システムが独立してではなくその至るところで、適切な是正処置及び予防処置が実施される
ことを保証しなければならない。
3.9 重大なデータ・インテグリティの事件が発見されたら、規制当局への適切な通知がされなけ
ればならない。
3.10 ガイダンスは’ALCOA +’よりALCOAを参照する。ALCOAは帰属性、判読性、同時性、原本性、
正確性、’+’は完全性、一貫性、耐久性/普遍性、利用可能性を意味する。データ・ガバナ
ンスの方法は、データのライフサイクルを通じて、データが完全で、一貫性があって、
耐久性/普遍性があって、利用可能であることを保証すべきであるから、どちらの頭文字が
使われても、データ・インテグリティの期待に違いはない。

4章 データ・インテグリティの重要性と固有のリスクの制定
4.1 データは、品質、安全性、有効性の判断において様々な重要性を持つ。データの重要性は、
データがいかに判断に影響を与えるかを考慮することによって決定されるかもしれない。
4.2 データへのリスクは、権限もなく、削除・修正・除外される可能性や、それらの活動や事象
の検知の可能性により判断される。データのリスクは、一貫して実施され、十分に定義され、
明確な目的を持った単純な作業に比べて、複雑さ、開放型の一貫しない処理、主観的な解析
によって増えるかもしれない。
4.3 データは下記の手段により生成されてよい。
(i) マニュアルの観察や作業による紙の記録
(ii) シンプルな機械から、複雑で高度に設定可能なコンピュータ化システムまでの、装置を
使った電子的な方法
(iii) 紙ベースと電子記録の両方がオリジナルの記録を構成するハイブリッドシステム
(iv) 写真、画像、クロマトグラフィ―プレートのような、その他の方法
データ・インテグリティのリスクを減らすために適切に構成された利用可能な技術の使用
が検討されるべきである。
設定可能なソフトウエアがなく、電子的データを保存しないシンプルな電子的システムは、
キャリブレーションのみが要求されるだろうが、複雑なシステムは“意図した目的のための
バリデーション”が必要となる。
バリデーション作業は、複雑さやリスク(ソフトウエアの機能、設定、ユーザの介入の
チャンス、データ・ライフサイクルの考慮により決定される)により増える。
4.4 管理方法の作業と/または頻度の軽減は、データが製品・患者に与える影響が少ないこと
や、又はハイレベルのシステムや専門家でなければ修正するチャンスがないプロセスで取得
される環境であることにより正当化されるだろう。
4.5 データ・インテグリティ・リスクアセスメントは、手順に従うことや機能を実行することが
要求されるファクタを考慮すべきである。コンピュータ化システムだけでなく、それを支える
人、ガイダンス、訓練、品質システムも考慮することが期待される。だから、それゆえに、
自動化や、バリデートされたシステムの使用は、データ・インテグリティのリスクを取り除き
はしないが、リスクを下げるだろう。人の介入がある場合、組織の不十分な管理や、システム
のバリデートされた状態への過度の依存によるデータの不十分な検証により、リスクは増加
するだろう。
4.6 データ・インテグリティ・リスクアセスメントで改善が強く求められた部分は、アクション
の優先順位付けが文書化され、経営陣に伝えられ、レビュの対象とされなければならない。
長期の改善アクションに分類された場合は、暫定期間内で容認可能なデータ・ガバナンスを
実施するための短期間のリスク軽減方法が実行されなければならない。

5章 データ・インテグリティを保証するためシステムと手順の策定;正しい環境の作成
5.1 システムと手順は、データ・イングリティの原則の順守を容易にする方法で策定されなければ
ならない。そのためには、これに限定されないが、下記のことが望まれる。
・データが複数の場所を通じて使われる場合、使用時に、タイムゾーンを識別し特定し、(活動の)
再構成とトレーサビリティを保証するためにイベントの時間を記録するための適切に管理/同期
されたクロックへのアクセス
・非正式なデータの記録と、後での正式記録への転記が起きないように活動が行われる場所での記録
の利用可能性
・ローデータ/ソースデータの記録のためのブランクペーパーへのアクセスは適切に管理されなけれ
ばならない。突き合わせ、またはページ番号のついた管理されたブックの使用が、記録の再作成を
防ぐために必要かもれない。これが実用的でないカルテ(GCP)のような例外はあるかもしれない。
・許可のないデータの修正を防ぐユーザアクセス権限(防止が不可能な場合は監査証跡)
 バーコードスキャナ、IDカードリーダ、プリンタのようなコンピュータ化システムを使った、
マニュアルのデータ入力や人の介入をなくす外部装置やシステムインタフェースの使用
要求された通りの作業の実施やデータの記録を可能にする作業環境の提供(例:適切な空間、
十分な作業時間、適切に機能する装置)
・データレビュ作業を行う職員のオリジナルの記録へのアクセス
・管理された印刷物の突き合わせ
・全ての適切な職員へのデータ・インテグリティの原則の十分な教育
・リスクアセスメント作業における専門家(Subject Matter Expert)の参加
・データ・ガバナンスに関係する品質測定基準の管理監督
5.2 他の作業者の代わりに作業を記録する筆記者の使用を検討することができる。例えば、
・同時の記録が製造や作業を危うくする作業 例:無菌作業者によるライン介入の文書作成
・解剖(GLP)
・文化的または読み書き/言語の制約に対応するため:例えば、ある作業者が作業を実施し、第二の
人間により立ち会われ記録される場合
   データの重要性により導かれる作業の適切な管理を保証する一方で、アクセス、使いやすさ、
使う場所の容易さも検討もされるべきである。
   これらの状況では、第二の人間による記録は、作業が実施されているのと同時であるべきで、
また、記録は作業を実施した人間と記録を完成した人間を識別すべきである。作業を実施した
人間は、可能であれば記録に連署すべきだが、この連署作業が過去に遡っても容認される。
監督(筆記者)の文書の完成作業は、作業が適用される活動を指定する承認された手順の中で
記述されるべきである。

6章 用語の定義と要求事項の解説
6.1 データ(★省略:原文をご確認ください)
6.2 ローデータ(ICH GCPで定義された”ソースデータ”と同義)(★省略:原文をご確認ください)
6.3 メタデータ(★省略:原文をご確認ください)
6.4 データ・インテグリティ(★省略:原文をご確認ください)
6.5 データ・ガバナンス(★省略:原文をご確認ください)
6.6 データ・ライフサイクル(★省略:原文をご確認ください)
6.7 データの記録と収集(★省略:原文をご確認ください)
6.8 データ転送/データ移行(★省略:原文をご確認ください)
6.9 データ処理(★省略:原文をご確認ください)
6.10 データの除外(GPvPは適用外)(★省略:原文をご確認ください)
6.11 オリジナルの記録と真のコピー
 6.11.1 オリジナルの記録(★省略:原文をご確認ください)
 6.11.2 真のコピー(★省略:原文をご確認ください)
6.12 コンピュータ化システムのトランザクション(★定義は省略)
複数の操作が、単一のトランザクションに結合されることは避けるべきである。
6.13 監査証跡(★定義は省略)
・データの変更には日付と時間が付けられなければならない。(当てはまる場合は、タイムゾーン
も付ける)
いかなる変更の理由も記録されなければならない。
・監査証跡は(リスクアセスメントで必要と判断された場合)、スイッチを入れて作動されなけれ
ばならない。ユーザは監査証跡を修正したりスイッチをオフにしたりできるべきでない。
システムアドミニストレータが修正したりスイッチをオフにしたりする場合はそのアクションは
保持されなければならない。
・監査証跡機能が存在しない場合、例えば、手順をSOPに定義しログブックを使用するといった
別の管理でも達成できるかもしれない。別の管理が有効であることが示されなければならない。
6.14 電子署名(★定義は省略)
電子署名の利用は次のことを考慮して適切に管理されるべきである
 ◎どのように署名を個人に帰属させられるか
 ◎署名が変更されることや、巧みに操作されることができないように、どのように署名のアクション
がシステム内に記録されるか
 ◎署名の記録が入力内容と関連づけられ、いかに検証されるか
 ◎電子署名のセキュリティ、すなわち、署名が、署名の所有者によってのみ使用されること
・電子署名の使用は、国際的な基準の要件に従わなければならない。電子署名またはE-署名システム
は、署名のマニフェステイション、すなわち、誰が署名したか、日付(重要であれは時刻)、署名の
意味(例:確認or承認)を明らかにした、見ることのできる記録の表示を提供しなければならない。
・文書が電子的に署名されたことを示す、バリデートされた電子署名処理以外の方法による署名画像や
脚注の挿入は適切でない。文書が電子的に署名されたら、署名と関連付けられたメタデータが保持
されなければならない。
6.15 データのレビュと承認
重要なデータとメタデータ、バツ印で消された文字(紙の記録)と監査証跡(電子記録)のよう
な特別な記録の中身をレビュする取り組みは、適用される規制要件を満たし、リスクベースで
あるべきである。
データのレビュと承認の手順を述べた手順書が存在すべきである。
手順書には、データのレビュにおいて、間違いや脱落が見つかった場合にとられるべきアクション
を記述すべきである。この手順は、データの修正や説明を可能にすべきである。
6.16 コンピュータ化システムのユーザアクセス/システムアドミニストレータの役割
・ある種のコンピュータ化システムは、単一ユーザのログインや限られた数のユーザのログインしか
サポートしていない。適切な代わりとなるコンピュータ化システムが利用できない場合は、サード
パーティのソフトウエアや、トレーサビリティを提供する紙ベースの方法によって同等の管理ができ
るかもしれない。代わりの管理方法の適合性は正当化され文書化されなければならない。ハイブリッド
システムは、脆弱でデータ変更の出所が不明なので、データレビュを増やすことを要求されるかもしれ
ない。企業には、現在の規制の期待に従ったシステムを導入することが期待される。
・システムアドミニストレータは、組織の大きさや性質を考慮に入れ、最小の人数に制限すべきである。
 全体的なシステムアドミニストレータ権限は日常的に使用可能であるべきでない。
・システムアドミニストレータ権限(データの削除、データベースの修正またはシステムの設定の変更
を許可する)は、データに直接の利害関係を持つ個人(データの作成、確認、承認)には与えられる
べきでない。
6.17 データの保管
・データの保管は、アーカイブまたはバックアップになるだろう。
・紙で作成されたデータは、バリデートされたスキャン手順の使用により保管されるだろう。
 6.17.1 アーカイブ(★定義は省略)
 ・アーカイブされたデータは、オリジナルの記録または真のコピーかもしれない。それらは、検知
  されずに変更されたり削除されたりしないよう保護されなければならない。また、火事や有害生物
  のような予期しない損害からも保護されなければならない。
 ・レガシーシステムがもはやサポートされない場合、データのアクセス可能性の目的でソフトウエアの
  保持の検討がされるべきである。これは、仮想環境でソフトウエアを保持することにより達成される
  かもしれない。
 6.17.2 バックアップ(★定義は省略)
 ・バックアップとリカバリの手順は、バリデートされ、定期的にテストされなければならない。
  各バックアップは、それが正しく機能したことを保証するために、例えば、オリジナルの記録と
  データのサイズが合うことの確認などにより、確認されなければならない。
6.18 ファイル構造
   データ・インテグリティ・リスクアセスメントは、ファイル構造の明確な理解を必要とする。
   GXP環境の中でデータが構築される方法は、データが何のために使われるか、どんなエンドユーザ
   が持つかによるかもしれない。
   属性により異なるファイル構造は、異なる管理やレビュ方法を必要とするかもれない。また、
   異なる方法でメタデータを保管するかもしれない。
6.19 意図した目的のためのバリデーション(GMP:Annex11,15も参照のこと)
   コンピュータ化システムは、規制要件と関連するガイダンスを順守すべきである。これらは、
   意図した目的のためにバリデートされていなければならず、それは、工程内でコンピュータ化シス
   テムの機能の理解を必要とする。この理由により、システム設定やユーザの意図した目的から
   離れたベンダの提供するバリデーションデータの採用は、容認できない。工程やエンドユーザの
   ITインフラから離れたベンダの試験は、機能の確認だけに限定され、性能適格性評価(PQ)の
   要件を満たさないだろう。
6.20 ITサプライヤとサービスプロバイダ(クラウドプロバイダや仮想サービス/プラットフォーム
   (SaaS、PaaS、IaaSも含む)を含む)
   クラウドや仮想サービスを用いる場合、提供されるサービス、所有権、データの保管とセキュリ
   ティの理解に注意が払われるべきである。
   その地理的な場所に適用可能な法律の影響も含んで、データが保管される物理的な場所が考慮され
   るべきである。
   委託者と受託者の責任は、技術合意書または契約書内で定義されるべきである。これは、要求に
   より、データの所有者や国の所轄官庁がデータ(メタデータや監査証跡を含む)へのタイムリー
   なアクセスを保証すべきである。プロバイダとの契約では、保管期間を通した、データのアーカイブ
   の責任や継続した可読性を定義するべきである。
   ソフトウエア/システムをオリジナルのバリデート状態に復元するために、バリデーションや変更
   管理の情報を含む適切な取り決めが、存続するべきである。
   事業継続の取り決めも契約の中に含まれ、テストされるべきである。サービスプロバイダの監査の
   必要性は、リスクに基づくべきである。

7章 用語集
このガイダンス内で使用される用語の説明が載っています。

8章 参照
このガイダンスで参照している文書が載っています。

本文:
https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/687246/MHRA_GxP_data_integrity_guide_March_edited_Final.pdf

その他出典:
https://mhrainspectorate.blog.gov.uk/2018/03/に09/mhras-gxp-data-integrity-guide-published/
https://www.gmp-publishing.com/en/gmp-news/gmp-aktuell/mhra-data-integrity-gxp-final-2018.html


◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
まとめ
◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆
いかがでしたでしょうか。
ガイダンスの中に、個人的に何点か気になる点がありましたので、以下にピックアップしたいと思います。
●紙の記録
データ・インテグリティに関する指摘を受けると、よく、 “そんなにデータ・インテグリティ、データ・
インテグリティというのなら、いっそコンピュータを使うのをやめて紙の記録に戻そう”とおっしゃる方
がいらっしゃいますが、残念ながら、ガイダンスの3.7章に、自動化システムまたコンピュータ化システム
から、紙ベースのマニュアルのシステムへ戻っても、データ・インテグリティの管理が必要だと明記されて
いますので、ご注意ください。

●経営陣の責任
3.1章でデータ・インテグリティに関する経営陣の責任が明記されています。
FDAがウォーニングレターの中でデータ・インテグリティに関する指摘をする際、企業のデータ・インテ
グリティに関する管理戦略について回答を求めていることからもわかるように、データ・インテグリティの
不備は、現場の一担当者がどうにか対処して済ませられる次元の話ではなく、会社として真剣に取り組む
べき重大な問題であるのがよくわかります。

●クロック問題
最近、時刻の管理に関して指摘を受けたという製薬会社様の話を非常によく聞きますが、5.1章に、
クロックの話やタイムゾーンの識別の話が出てきています。どんなに同時性を意識して記録を作成しても、
そもそもシステムの時刻がずれていたのでは、データ・インテグリティは保証できません。
適切に管理/同期されたクロックが不可欠です。
また、グローバルな会社様は、タイムゾーンにも注意を払う必要があります。

●当局の期待
ありがたいことに、MHRAは、監査証跡の残せないシステムやアクセス制限が出来ないシステムを絶対禁止
とはいっていません。しかし、“企業には、現在の規制の期待に従ったシステムを導入することが期待
される (6.16章) ”や、“自動化やバリデートされたシステムの使用は、データ・インテグリティの
リスクを取り除きはしないが、リスクを下げる(4.5章)”といった記述を見ると、MHRAが十分な機能を
備えたコンピュータ化システムの導入を望んでいることは明らかなように思います。

●クラウド登場
6.20章において、クラウドや仮想サービスを用いる場合、提供されるサービス、所有権、データの保管と
セキュリティを理解することが求められています。
クラウドや仮想サービスの利用は、システム管理者の作業負荷が軽減でき、コスト削減がはかれると
いうメリットに目がいきがちですが、サービスプロバイダに全てお任せというわけにはいかないという
ことを忘れてはいけないと思います。

個人的に気になる点をピックアップしましたが、他にもデータ・インテグリティに関する重要なことが
書かれているガイダンスです。
時間のある時に是非目を通しておかれることをお勧めします。


☆次回は、4/13(金)に配信させていただきます。


◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇
★弊社サービスのご案内
https://drmarketing.jp/cch/73/148/3/426/91894/bc7108

★ブログ毎日更新中!
◆ PROS.社長の滋養強壮ブログ
https://drmarketing.jp/cch/73/148/1/426/91894/e57105
◆ 営業ウーマンの営業報告ブログ
https://drmarketing.jp/cch/73/148/2/426/91894/f8bdc8
※URLクリック数の統計をとらせていただいております。

本メルマガは、名刺交換させていただいた方に、毎月1日、15日(土日祝日に重なった場合
は前日)に配信いたしております。
今後このような情報が必要ない方は、お手数ですが、こちらに配信停止依頼のメールを
お願いいたします。
hashimoto@e-pros.co.jp

【発行責任者】
株式会社プロス
ASTROM通信』担当 橋本奈央子