前回、アカデミア におけるバリデーションの苦悩について独り言を綴ってみました。「導入先が良いといえば、良い！」と突き放すような事を書きましたが、誤解が無いように補足：どうでも良い、と言う意味ではありません。ただ、自施設が監査を受ける際に、「ベンダーが良いと言ってた」はあまり説得力が無いものだと想像します。ちょうど前回の投稿の翌日に、訪問先で偶然にもアカデミアxバリデーションの話があがったので、やはり皆さん大変困ってらっしゃるのだな、と言う印象です。
前回も触れましたが、CRO、特にIT系のCROに外注出来るなら手っ取り早いです。ですが、バリデーションの全てを外注するのは、（一般的には）アカデミアには敷居が高いと思われます。そうなると一部のみを委託、残りを自施設で行うなどや、アカデミア同士で連携して一緒に作り上げる…と言うのが自然だと思われます。ベンダーとしてここで出来ることは、ユーザー会の設置・後援であったり、ユーザー同士のディスカッションの場を提供することでしょうか。ここは我々の課題ですので、今年中に実現出来るように努めます。
というわけで、今回はバリデーションの一環で行われますPQ（Performance Qualification；適格性確認）というものについて、僭越ながら少しポイントを。どのEDC/CDMSも基本的に特記事項の追加は自由に行える設計になっておりますが、これらを運用に盛り込む場合、監査証跡に正しく反映されているのが必要になります。この場合にPQスクリプトに含まれてなければいけない項目として：
- 特記事項を作成
- 監査証跡の確認（特記事項が生成された旨が確認できるかをチェック）
- 特記事項に変更を加えてみる
- 監査証跡の確認（特記事項の内容に変更が加えられた旨が確認できるかをチェック）
- 特記事項を削除
- 監査証跡の確認（特記事項が削除された旨が確認できるかをチェック）
上記の6項目に対して、それぞれ結果を記録します。想定される結果を文書に先に起こして、満たされていれば「YES」とするでも良し、その都度結果を、例えばスクリーンショットを添える等して書き起こすも良し、です。後者の方が情報量という観点からも、「おお、仕事やってるな！」という見栄えの面でも優れているのですが、当然、必要労力も2倍になります。さて、上記は比較的シンプルなものですので、もう一つ例を挙げます。ユーザー別で、実施施設へのアクセスが正しく制御されているのかを確認する場合です：
- 準備：施設A、B、Cと三つの実施施設を準備し、施設Aに対して書き込み権限、施設Bに対して読み取り権限、そして施設Cに対して権限なしのユーザーアカウントを準備する（それぞれのアクセス権限設定は、プリントアウトできるならする、出来ないなら設定画面のスクリーンショット）。また、（管理者アカウント等を用いて）あらかじめ施設A、B、Cのそれぞれに患者を一例以上登録しておく。
- ユーザーアカウントでログインする
- 施設Cの患者が表示されないことを確認する
- 施設Aに新たな患者の登録を試みる（正常に登録完了できる旨をチェック）
- 施設Bに新たな患者の登録を試みる（読み取り権限のみのため、不可である旨をチェック）
- 施設Aの任意の患者のデータ入力を試みる（正常にデータ入力が行える旨をチェック）
- 施設Bの任意の患者のデータ入力を試みる（全てのフォームがデータ入力・更新不可である旨をチェック）
- 施設Aに対して、クエリや特記事項の操作を試みる
- 施設B同上…
- 該当する場合、UNSCHEDULEDについても同様に6~9を確認
- 施設Cに対して書き込み権限、施設Bに対して読み取り権限、そして施設Aに対して権限なしの別のユーザーアカウントを作成し、同様に2~10を確認
なお、10と11は短く記述しましたが、テストと確認結果の見やすさを考えると、実際のPQを行う際には1~9の様に別の項目を立てることが必要です。ここで紹介したのは2例のみですが、こういった類いのものがシンプルなEDC/CDMSでも100～200は発生します。少し余談になりますが、システム選びの際に「色々出来る！すごい！」と言うのに惹かれて後先考えずに導入してしまうと、PQの段階で大変なことになります。多機能なシステムを導入するに超したことはないですが、機能の使う・使わないはしっかりと取捨選択した方が賢明だと思います。
コメント