データインテグリティーはなぜ今もホットトピックなのか？｜品質マネジメントシステム（QMS）管理ソフトウェアならマスターコントロール
vol.02
- 品質マネジメントシステム（QMS）管理ソフトウェアならマスターコントロール
- > コラム >
- データインテグリティーはなぜ今もホットトピックなのか？
- CONTENT
- データインテグリティー
- ALCOAの原則
- 査察の傾向と課題
- 解決策
データインテグリティー
FDAやPIC/S、MHRAなどがデータインテグリティーに関するガイダンスを発行した後、データインテグリティーという用語は、ニュースや雑誌、セミナーなどで頻繁に取り扱われるキーワードとなり、ガイダンスが発行され数年がたった後でも、その扱いに大きな変化はみられません。また、実際の査察事例などを見ても、多くの企業でデータインテグリティーに関連する指摘が確認されており、一部ではその対応に苦慮しています。
データインテグリティーとは？
ライフサイエンス業界において、主要な行政機関や団体からガイダンスが発行されており、その中に定義が記載されていますので、まずは、それを見て行きましょう。
-
FDA
データインテグリティーとは、データの完全性、一貫性、そして、正確性のことである。そして、そのようなデータはALCOA原則に基づいている。
-
PIC/S
データインテグリティーとは、ライフサイクルを通じて、完全性や一貫性、正確性をデータが持っていることである。
-
MHRA
データインテグリティーとは、ライフサイクルを通じて、完全性や一貫性、正確性をデータが持っていることである。
-
WHO
データインテグリティーとは、完全性や一貫性、正確性を有し、信頼でき且つ頼りになるデータのことであり、そのような特徴がライフサイクルを通じて維持されていることである。
参考文献
PIC/S：GOOD PRACTICES FOR DATA MANAGEMENT AND INTEGRITY IN REGULATED GMP/GDP ENVIRONMENTS 2018年11月30日
MHRA：GXP Data Integrity Guidance and Definitions 2018年3月
WHO：Guidance on good data and record management practices 2018年3月
実際の要求事項の記載内容は、各ガイドラインで一致しない点もありますので、本格的に対応を検討する場合、要求事項も含めて検討する必要はありますが、定義という点に限定すれば、記載方法に大きな違いはないのがご確認いただけると思います。
データインテグリティーとは、個々のデータ自体に限定せず、作成から廃棄までのライフサイクルが対象になっていること、また、データというとソフトウェアで作成した電子データのみが対象と考えがちですが、データインテグリティーの観点では、「データとは情報である」という捉え方に近く、電子データに限定せず、紙に印刷した文書や手書きの記録などもデータとして考える必要があります。
一方で、全てのデータは何らかの業務を通じて作成されるものです。その視点から考えると、従来の法規制やガイドラインは 業務に焦点があたっており、前述のガイドラインの全てが新しい要求事項と捉える必要は必ずしもないと考えることもできます。
ALCOAの原則
ALCOA原則は、データインテグリティーを実現する上で必要となるデータの特性を示した原則で、
下記の5つの単語の頭文字の組み合わせが語源となっています。
-
Attributable = 帰属性
ある作業を行った上で記録（データ）が作成されたケースを例にすると、作成されたデータの内容に加えて、誰が作業し、データは誰が作成したのか、その作業を行った日付や時刻といった情報が必要であり、そのデータに変更が発生した場合も同様の情報が求められます。
つまり、そのデータを「 誰が、どうやって、いつ」作成したのかという ことが明確にできる必要があるということです。 -
Legible = 判読性
対象となるデータは、常にアクセス可能で、判読可能な状態で管理・維持する必要がある点を求めています。ここでいうデータとは、記録自体に限らず、その記録に付帯する基本情報も対象となり、他のデータとの関連性に関する情報までを含めて管理する必要があります。 -
Contemporaneous = 同時性
作業をする際に記録も作成することが求められており、バックデートなどを禁止するのがこの同時性です。
例えば、何かの検証作業を実施しているケースであれば、各検証作業を実施することと平行で、記録も作成する必要があり、その記録には、日付や担当者情報なども含める必要があります。また、手順書の記載内容からも連動していることが認識できる必要もあります。システムで運用しているケースであれば、アプリケーションが使用する日付が、タイムサーバーと正しく連携できているといった点も、この同時性を実現する上では重要です。 -
Original = 原本性
作成されたデータの原本がどれなのかという点を明確にする必要があるのが、この原本性です。手書きの記録からシステム入力した場合であれば、原本である手書きの記録をシステムに転記したという解釈になり、この転記作業に適切な検証作業を含める必要があります。ここでいう原本とは、記録自体の基本情報（メタデータ）まで考慮する必要があり、これらに対する変更も含めて考慮する必要があります。 -
Accurate = 正確性
正確なデータとは、内容に不備がなく、発生した内容を記録しているケースであれば、その発生内容が正しく正確に記録されているというのが、この正確性で求められている内容です。計測機器などを使用しているケースであれば、その機器が計測した結果が正しいことも定期的にチェックする必要があり、システム利用前のバリデーションも同様の理由で必要となります。
ALCOA+
その後、PIC/SやMHRAなどのガイダンスでも記載されているALCOA+という原則が登場し、前述の５つに下記の特性が追加されました。データを管理する際、これらの項目を運用に反映し、メタデータなどで情報を組み合わせながら、各データを運用していくことが、この原則では求められています。
-
Complete = 完全性
全てのデータが削除されることなく存在していることが、この完全性では求められます。対象データに変更が生じた場合でも、その変更を実施した担当者や日付を含めて判別することができる必要があります。 -
Consistent = 一貫性
発生から調査、対応といった時系列で複数の作業が実施されている場合、一連の作業とその日時に矛盾がない状態で作成されていることが、この一貫性で求められており、各データのライフサイクルを通じて、この合理性が存在している必要があります。 -
Enduring = 永続性
ここでは、データや記録の耐久性が求められており、内容が理解できる形で保存されていることを含めて、考慮する必要があります。電子データであれば、10-20年後もファイルの中身が閲覧できる、紙であれば、記載内容が同様の期間で消えてしまうといったことがないように気を付ける必要があります。 -
Available = 可用性
データの管理が求められる期間中、そのデータが常にアクセスできる状態であることが、この可用性では求められています。このアクセスできる状態とは、査察や監査時に要求された際に開示し、閲覧できる状態も考慮する必要があります。
データインテグリティーの現状
データインテグリティー関連の話題は、セミナーや雑誌等でも頻繁に取り上げられている一方、ガイドライン自体は、当初の発行から既に数年が経過しています。しかし、増え続けてしまうデータの特性の影響か、FDAの査察結果を見てみても、関連する違反が継続しているのが現状です。また、悪意のある事例も一部はありますが、文化の違い（空き番の扱いなど）から指摘事例に繋がってしまっているケースもあり、グローバルにビジネスを展開する企業にとっては、法規制準拠という観点をより広い視点で検討する必要もあります。
また、データの改ざんなどの問題は、ライフサイエンスに限らず、様々な業界で発生しており、自動車業界などでは数万台のリコールに発展するなど、実際の消費者にも影響を与える重要な問題と位置付けられています。
データインテグリティーが今後もライフサイエンス業界における重要なポイントであり続ける理由を説明する前に、これまでに発表された法規制やガイドラインを確認し、ありがちな課題について確認していきましょう。
そのような事例を確認することで、より
効果的にデータインテグリティーを管理できるプログラムに繋げていけるのではないかと思います。
査察の傾向と課題
FDAがここ数年の懸念としてデータインテグリティーを挙げていることは、Warning Letterの数を把握するだけでも
容易に理解することが可能で、2016年は全体の15％、2017年は18％、そして、2018年には25％に上昇しています。
また、これらのWarning Letterを見てみると、同じようなポイントが繰り返し指摘され続けており、製造記録や試験データの不備、システム内の権限に関する指摘は、データインテグリティーに関する指摘の中でも常に上位を占める事例です。また、多くの指摘事項では、品質システムにおける特定の業務プロセスの欠如や不備といった点が証拠として示された内容から把握することもできます。
しかし、このような事例で注視すべきポイントは、品質システムの一か所に課題が見つかったという事実は、他の箇所にも問題が潜在していると考えるのが自然であり、このような課題はデータインテグリティーを構成する基本的な要素に問題を抱えている状態であるということを認識しなくてはいけません。
その為、このような事実がデータインテグリティーに対して確認された企業の場合、データインテグリティーだけでなく
品質マネジメントシステムレベルでも相当な問題を抱えていると推測されてしまいます。
解決策
ここから紹介するポイントは、データインテグリティー対応への導入において、効果的であった解決策をご紹介します。
しかし、各企業の事業内容は異なりますので、その特徴を適切に理解した上で、最適なアプローチを取ることが必要となりますので、ご注意ください。
データのライフサイクル
を理解する
導入が比較的簡単な解決策とは、現在の運用内容に近い手法を用いた方法です。例えば、新しい機器や機材を導入する場合、既存の業務に沿った要件で手配したものであれば、その導入も簡単になります。しかし、導入したソフトウェアがデータインテグリティーを支援する機能を搭載していても、ライフサイクルやデータの流れを理解せずに運用するのでは意味がありません。
特に複数の分野にて横断的に運用されるようなデータを検討する際は、一般的にも知られるPLM（プロダクト ライフサイクル マネジメント）の考え方を意識して検討するのがお薦めです。
製品を製造する場合、製品の品質を担保する為に必要となる様々な工程が予め定義されており、その一つ一つのステップを通過することで、製品の品質を保証するというのが基本的な考え方かと思います。データインテグリティーの考え方もこれに似ていて、データに対する処理や検証といったステップを予め定義し、その通りに進めていくことで保証することができます。
推奨する戦略
-
データがどのように計測機器や紙運用の現場から移動していくかについて検討し、その作成から終わりまでの工程の一つ一つを確認していきましょう。
-
データの品質維持こそが目標であると考え、データインテグリティーを保証する上で必要となる新たなプロセスや修正内容を検討していきましょう。
自社におけるGxPのデータの流れを
文書化する（データのライフサイクル）
データのライフサイクルが把握できたら、次はライフサイクルにおけるプロセスの文書化です。製造施設の場合、このプロセスはバッチ記録からスタートし、GxPに関わる保守記録や教育記録などに関連していきます。GxPにおけるデータの流れを文書化することは、プロセスの管理者とデータの利用者にとっての重要度や優先度などの情報を把握することに繋がります。同時に、データと業務プロセスの結びつきも把握することに繋がりますので、業務効率の改善などに役立てることができます。
推奨する戦略
-
ライフサイクルにおける各ステップの定義を含めて、GxPに関わるデータの流れを紐づける。
-
データのフローチャートを作成し、プロセスの管理者とデータの利用者も参照できるような文書として運用する。
データインテグリティー向けの正式な計画
を立てる
品質システムにデータインテグリティーの要素を取り入れることは、短期的なプロジェクトを遂行するというより、企業文化を変えるというニュアンスの方が強い活動です。
その為、データインテグリティーを保証する為に必要な各作業を定義し、プロジェクトとして計画が完成したら、承認手続きを取る必要があります。査察官の立場で考えれば明らかですが、口頭で「現在、データインテグリティーの強化に取り組んでいます」と伝えてくる企業より、適切に文書化された計画に沿ってデータインテグリティー強化を進めている企業の方が印象が良いと思います。
また、このような計画を立てる際、自社の現在の状況を正確に把握するようにしましょう。これには、既存の品質システムに対するデータインテグリティーの関連性や、導入を予定しているデータインテグリティー対策の要旨なども定義する必要があります。このようなポイントは、後々、問題につながるケースが多いので、必ず確認しましょう。
推奨する戦略
-
データインテグリティー強化の為、既存のシステムと新しく導入するシステムの管理方法の詳細について適切な手続きを踏みながら計画していきましょう。
-
QMSを次のレベルに引き上げることを意識して、新しい品質システムの導入を行いましょう。その際、下記の点にも注意してください。
- GxP対象となるデータがどれなのかを定義する
- GxP対象のデータに対するライフサイクルを定義する（通常は文書の種類毎）
- GxP対象となるデータが含まれるシステムに存在するリスクへの対応や品質管理プロセスの導入（検証や維持を含めて）
- 既存システムに対する評価を行い、データインテグリティーの管理に影響を与える課題に対する対処を行う
本章のまとめ
データインテグリティーの強化や対策を既存の品質システムに導入することは容易ではありません。
特定の業務プロセスの改善や製造機器の導入といった案件は多く経験されていると思いますが、データインテグリティーは従来とは大きく異なる性質を持っています。
それは、複数の業務プロセスやソフトウェア、手順書、さらには組織を横断しながら保証する必要があるプロセスであるという点です。その為、データインテグリティーを検討する際、まずデータを製品として考えることをお話しました。それは、製品のライフサイクルと同様に、データに対する適切なライフサイクルの理解がデータインテグリティーの対策において極めて重要だからです。この考え方に思考を転換することで、データインテグリティーの悩みから解放される企業が増えることを願っています。
本投稿は、英語の文献を元に翻訳または抄訳及び校正を行っており、本サイトに掲載されている全ての情報や画像の著作権は、当社（マスターコントロール株式会社）に帰属します（他社提供のクレジット表記入り画像等を除く）。コンテンツの再発行及び再配布は、個人利用の場合を除き、当社より許可を得た場合のみ可能です。また、本ブログを含む当社のWebコンテンツを利用することで発生する損害やトラブルについて、当社は一切の責任を負いません。
