2016年10月

2016年10月27日

こんにちは

以前チラッと話題にした、お気に入りのテレビドラマの新シリーズが始まりました。(オフィスでは、ちょうどラジオからドラマのエンディング曲が流れてきています
コマーシャルの間、気になるキーワードが聞こえてきてふと視線を戻すと、やはり今回もS川急便さんです。

物流は比較的身近で接することが多い業界ですが、お仕事で関わるようになるまでは深く考えることもありませんでした。
今回のコマーシャルは、そんな物流業界以外の人たちにも物流っておもしろそうだな、かっこいいなと思ってもらえるような内容になっていて、現場のスピード感もリアルに伝わってきます。

S川急便さんのホームページでも公開されていますので、気になる方はぜひご覧ください




さてCSVのお話に戻り、今日はテストの省略を語る前に押さえておきたい、検証業務で実施すべきことです。

ここでは、厚生労働省「コンピュータ化システム適正管理ガイドライン」で挙げられている検証業務の作業を整理してみます。

・バリデーション計画書の作成
・詳細なリスクアセスメント
・設計時適格性評価(DQ)
・供給者監査
・据付時適格性評価(IQ)
・運転時適格性評価(OQ)
・性能適格性評価(PQ)
・バリデーション報告書の作成


<バリデーション計画書の作成>
検証業務全体の方針をまとめます。
今回のテーマである開発テストの結果引用などは、計画の段階でどうするか定めることが必要です。

<詳細なリスクアセスメント>
システムの機能毎にリスク分析をします。
機能仕様書の機能一覧に対して実施することが多いです。

<設計時適格性評価(DQ)>
ユーザ要求仕様書の要求事項が漏れなく設計に反映されていることを確認します。
トレーサビリティマトリクス(詳細はこちら)を用いることが一般的です。

<供給者監査>
供給者による開発業務を監査します。
プロジェクトの初期に供給者アセスメントで確認した品質管理システムの通りに開発業務が行われていることを確認します。
システムテストの終盤に実施することが多いです。

<据付時適格性評価(IQ)>
ハードウェアの設置とソフトウェアのインストールが適切になされていることを確認します。

<運転時適格性評価OQ>
機能仕様書を基に、システムの機能をテストします。
リスクアセスメントの結果に応じてテストの内容を決定します。
(例:カスタマイズ機能は必須、リスクが高い機能は必須、ERES機能は必須 など)

<性能適格性評価PQ>
業務の流れに沿ったシナリオでテストを実施し、ユーザ要求事項を満たしていることをテストします。

<バリデーション報告書の作成>
バリデーションの結果を総括して報告します。


つづく




(10:53)

2016年10月20日

こんにちは

今日は、まずはこの場でブログ3周年目突入をご報告させていただきます
このブログを始めたのがちょうど2年前の2014年10月20日。
2年間ずっと見守って下さった方も、最近来ていただくようになった方も、検索して偶然いらっしゃった方も、本当にありがとうございます。

CSVを中心に、GDPなどのテーマも交え、今回の記事でなんと198回目の投稿となります。せっかくの記念日にキリ番200まで2回分足りなかったのがちょっと心残りです。

しばらくしたらデータインテグリティなんかも取り上げてみたいなと目論んでいます。
その日の気分で不定期に書いているCSVブログですが、これからも長くお付き合いのほどよろしくお願いいたします



さて、今日からまた新しいテーマです。今回は『検証業務でのテストの省略』について考えていってみたいと思います。

厚生労働省の「コンピュータ化システム適正管理ガイドライン」では、OQやPQなどで開発業務のテスト結果を引用することができるとなっています。

また、GAMPではというと、2008年に発行されたGAMP5からは、IQ、OQ、PQという考え方がなくなりました。

このような考え方の根本にあるのは、「重複した無駄なテストはできるだけやめましょう」ということです。規制対象企業にとっては直接コストにつながるのでもちろんですが、当局としても同じことを繰り返す手間を極力減らし、もっと重要なことに時間を割いてもらいたいというのが本音なのではないでしょうか。

そうはいっても、開発工程でどのようなシステムをテストするのかよくわからない製薬会社と、バリデーションでどのようなテストが求められているのかよくわからないシステム開発会社では、何が必要で何は不要なのかを正しく判断できていないのが実状です。

そこで、今回は厚生労働省の「コンピュータ化システム適正管理ガイドライン」で言われている流れで、どのようにすればテストの重複なく必要なテストを網羅できるかを見て行ってみたいと思います。

まず前提として、供給者によるシステム開発工程は「共通フレーム2013」に準ずることとします。
とはいえ、会社さんによって工程の呼び名はまちまちだと思いますので、IPAより出されているこちらの39ページの表の工程名称を使用することにします。さらに、システムテストの後には、受入試験を実施することとします。
開発工程名称

単純に開発工程とCSVの作業を対比してみると、以下ようになります。

要件定義=ユーザ要求仕様書
外部設計=機能仕様書
内部設計=設計仕様書
コーディング/テスト=プログラミング・プログラムテスト
OQ=結合テスト
PQ=システムテスト、受入試験

検証業務だけを見てみると、最も苦労するOQとPQは開発工程で既に実施されていることになります。

基本的な考え方は上記のとおりでよいのですが、だからといって全くOQ、PQを実施しなくてもよいというわけではありません。また、DQ、IQ、供給者監査といったその他の検証業務は、開発工程で重複することはないのでしょうか?

ということで、次回はもっと実践に踏み込んで、開発工程とCSVの検証業務を見比べて行ってみたいと思います。




(10:43)

2016年10月14日

こんにちは

今日はGDPの話題からです。

7月に製薬協で偽造医薬品対策セミナーが開催されていたそうです。
90名もの方が参加したとのことで、関心度の高さがうかがい知れます。

その際の報告が、こちらにありますので、ご興味ある方は見に行ってみてください。

個人的には、日本での偽造薬の摘発案件がアメリカ、中国に次いで3位ということが、思ってもみなかったことだったのでびっくりしました。


さて今日の本題、供給者17のことシリーズ、今回で最終回です。


★★★ ここから http://learnaboutgmp.com  の翻訳です ★★★

適切なソフトウェアを選択するには注意が必要で、正しい選択をするためには事前の計画を入念にしなければなりません。


クラウドベースの技術を採用する際は、バリデーションの過程全体においてどのように影響するかを見極める必要があるため、さらに難しくなります。


要求事項の概要を明確にし、他の経営者から同意を得ることを忘れないようにしてください。


<完>

★★★ http://learnaboutgmp.com の翻訳ここまでです ★★★
個人的に翻訳したものなので、誤りがありましたら申し訳ございません。
読者の皆さまご本人の責任でご判断をお願いします。



じほう社の「コンピュータ化システム適正管理ガイドライン解説」にも供給者アセスメントでの質問票のサンプルがあり、それを使用されている製薬会社さんも多いかと思います。
こちらでも下請け会社に関する質問がいくつかありますが、どちらかと言うと事実確認に近い内容で、品質システムそのものを問う内容とはなっていません。

今回の記事では、協力会社の品質システムに関する質問が17問中5問も挙げられています。
この状況を考えると、ここ数年で製薬業界でも開発現場の実態に合わせて協力会社の重要性が認識されてきているのではないかなと推測します。

製薬会社さんは、システムを提供する供給者だけではなくその協力会社の品質も保証できるように、供給者アセスメントの質問票を準備しておかなければならないかなと思います。



情報元:learnaboutgmpのHPより
http://learnaboutgmp.com/17-questions-you-need-to-ask-a-software-vendor-about-their-quality-system/





(12:27)

2016年10月03日

こんにちは

とうとう10月、今年は台風でバタバタしているうちにすっかり秋となってしまいましたね

近所の本屋さんに立ち寄ったら、新刊コーナーが手帳コーナーに変身していました。
2016年を振り返って笑顔になれるように、残り3ヶ月も充実した時間を過ごしていければと思っています。



さて、今回も前回に引き続き供給者アセスメントで品質システムについてどのようなことを確認すればよいのか、海外の記事を前回のつづきからご紹介です。



★★★ ここから http://learnaboutgmp.com  の翻訳です ★★★

<品質システムのアンケート>

  1. 貴社はで品質システムを確立し、文書化していますか?
  2. 品質システムは顧客の品質技術方針を適切に反映していますか?
  3. 品質に関わる責任はSOP等で定義されていますか? 責任者の資格条件は何ですか?
  4. 品質システム文書は、レビュー、承認、発行において適切に管理されていますか?
  5. 品質システム文書は定期的に見直され、適切にメンテナンスされていますか?(頻度は?)
  6. 内部監査やマネジメントレビューなどの品質システムの実績をレビューする手順はあります?か
  7. 教育訓練の手順書と職務記述書はありますか?それらは品質システムをメンテナンスするのに適切ですか?
  8. 製品の設計、開発、導入に関する品質計画書はありますか?
  9. 協力会社を利用しますか?
  10. 協力会社の品質システムを管理する方法はありますか?例えば、供給者アセスメント、仕様書、文書のレビューや承認など。
  11. 関連する協力会社の品質文書にアクセスすることはできますか?
  12. 協力会社の品質システムは上述の質問を満たすことができますか?
  13. 協力会社を監査したことはありますか?報告書をレビューしましたか?
  14. BS 5750 Pt.1や2、TickIT、ISO9000、その他(種類は?)の認証を取得していますか?
  15. コンピュータシステムにGAMPを適用してきますか?
  16. QCのSOPはありますか?有効な手順書はありますか?
  17. OOS(規格外)の手順書はありますか?
<つづく>

★★★ http://learnaboutgmp.com の翻訳ここまでです ★★★
個人的に翻訳したものなので、誤りがありましたら申し訳ございません。
読者の皆さまご本人の責任でご判断をお願いします。



情報元:learnaboutgmpのHPより
http://learnaboutgmp.com/17-questions-you-need-to-ask-a-software-vendor-about-their-quality-system/




(10:54)