2014年12月

2014年12月26日

おはようございます。

今日は2014年の最終出勤日です。
今年の10月から本ブログを始め、早や3か月が経とうとしています。
振り返ってみると、当初考えていたよりも頻繁に更新し、さらに記事も長くなり、スタートダッシュし過ぎてしまった感も否めません。
しかし、それもこれも皆さまがCSVブログを愛読していただいているからこそです。

ブログを書きながら、改めて調べ直したり、新たな発見をしたり、とても勉強になった3ヶ月でした。
また、ブログを通して色々な方と交流する機会が増えたことは、良い意味で想定外の出来事でした。

来年も楽しみながら続けて行けたらと思っていますので、引き続きご愛読のほどどうぞよろしくお願いいたします。

皆さまにとって来年が良い一年となりますように



(10:26)

2014年12月25日

おはようございます。
昨日はクリスマスイブでしたね。
会社のエントランスは楽しげなクリスマス気分です しかし、エントランスを横目にオフィスの中に入ってしまうと、いつも通りの仕事場です


さて今回も、今まで通り前回の続きなのですが、少し肩の力を抜いても大丈夫です。

4)DQを確認する。
DQ(設計時適格性評価:Design Qualification)とは、URS(ユーザ要求仕様書)の内容が、システムの設計書に全て反映されているかを検証することです。

DQでは、トレーサビリティマトリックスを作成して、URSの項目がシステムにもれなく反映されていることを検証していることが多いと思います。
したがって、DQがしっかり実施されているかどうかの確認は、トレーサビリティマトリックスを再確認することで可能です。

実施作業は複雑ではないので、それほど大変ではないかと思います。
査察対応としては、承認された計画書、実施記録、報告書があるかどうかを確認するくらいかなと思います。


5)IQを確認する。
IQ(据付時適格性評価:Installation Qualification)とは、システムがコンピュータに適切にインストール(導入)され、さらにそのコンピュータが適切に設置されていることを検証します。

インストールや設置は、システム開発会社などの業者が実施する方が多いかなと思います。
そのため、IQとしてはその業者が実施する作業報告書の確認をもって完了としている製薬会社さんが多いのではないでしょうか。

したがって、IQもDQと同様に、実施作業自体はそれほど複雑ではないため、査察対応としては計画書、実施記録、報告書があるかどうかを確認してください。

加えて、IQでは業者が作業する際に使用した、インストール手順書や設置手順書があるかも確認しておいてください。
これらの手順書があれば、運用中にコンピュータが故障してしまっても、代替のコンピュータを用意することができるので、災害対策の一環にもなります。(ただし、複雑なシステムでは、業者に依頼した方が確実です)

6)OQを確認する。
OQ(運転時適格性評価:Operational Qualification)とは、設計書通りの機能をシステムに備わっているかどうかをテストして検証します。

OQではシステムの機能毎に設計書の通りの結果が得られるかを確認します。重要で複雑な機能については、複数パターンをテストすることもあります。

OQの査察対応では、計画書、実施手順書、実施記録(結果の記録や画面ハードコピー)、報告書があり、OQで発生した障害が全て対処されていることを確認してください。

ここまで読んでもらって申し訳ないのですが、運用中やPQで重大な障害が出ていないシステムであれば、OQが査察で注目される可能性は少ないと思います。
ですので、冒頭で言っていたように、肩の力を抜いてご確認してもらって大丈夫です。


ラジオからはクリスマスの曲が流れています。もうしばらく、クリスマス気分に浸れそうです



(09:32)

2014年12月22日

こんにちは。

週末は年賀状を書こうと思っていたのですが、案の定(?)、手が付けられませんでした。なかなか計画通りには進みません。
しかし、CSVは逸脱となると余計な手間がかかるので、計画通りに進めましょう!

前回の記事で、「運用状況、バリデーション報告、URS・PQまでで大丈夫!」かな?と言ってしまいましたが、バリデーション計画書も重要でした。


3)バリデーション計画書を確認する。
「リスクアセスメント」でバリデーションの程度が決まり、バリデーション計画書作成時はその結果を反映してバリデーションの計画をたてるることになります。

バリデーション計画書では、下記の事項を確認してみてください。

ⅰ)CSV実施手順書(SOP)の通りに必要事項が計画されているか。
CSV実施手順書(SOP)には、バリデーション計画にて具体的に何を計画すればよいのかが記載されているかと思います。
たぶん大丈夫だとは思いますが、対象システムのバリデーション計画が、このSOPのとおりに計画されていることを、念のため確認しておいてください。

ⅱ)責任体制は明確になっているか。
システム開発会社など、外部の会社に何を依頼したのかがわかるようになっていると良いと思います。

ⅲ)リスクアセスメントの結果は妥当か。
業務担当者だけではなく、信頼性保証部やシステム部門からの目線でも確認することをお勧めします。
リスクアセスメントにて誤ってリスクを低く見積もってしまった場合、バリデーション活動が不十分となってしまい、指摘を受ける可能性もありますので、リスクアセスメントは慎重に行うようにしてください。

特に、業者が実施するシステムテストや受入テストの結果を引用し、OQやPQのテストを省略した場合などは、その妥当性を査察の調査担当者に説明できるように準備しておいてください。



(16:46)

2014年12月19日

前回はCSV査察の準備として、バリデーション報告書の確認ポイントまでを整理しました。

今回は、システム導入時のバリデーションで、一番重要なところの確認です。

2)URSとPQを確認する。

URS(ユーザ要求仕様書:User Requirement Specification)とは、システムを使用する業務担当者が、どんなシステムがほしいのかを書きまとめた文書です。

PQ(性能適格性評価:Performance Qualification)とは、URSの要求がシステムに反映されていることを確認するテストです。
PQでは、実際の業務に近い環境で、業務担当者が想定している運用手順に従ってテストすることになります。

ここでは、システムのSOP(操作手順書や管理手順書)を参考に、ユーザ要求やテスト項目に漏れがないことを確認します。これにはトレーサビリティマトリックス()を使用すると便利です。

セキュリティやバックアップなど、ER/ESなどの規制要件で要求されている機能も、忘れずにPQでテストされていることを確認してください。
ⅰ)ユーザ管理
ⅱ)電子署名(使用する場合)
ⅲ)操作権限
ⅳ)監査証跡
ⅴ)バックアップ・リカバリ  など

また、他のテストでも共通に言えることですが、障害が発生した場合は、すべてが対処され、再テストで問題なく合格したことを確認してください。
テスト記録(実施記録、画面ハードコピーなど)についても、障害が発生した箇所を中心に、実施者のサイン・日付とともに、テストの結果が記録されていることをしっかりと確認してください。

ここまでの内容が完璧でしたら、査察の調査担当者もそれ以上は追及せずに、CSVは問題なし!と言ってくれるかもしれません。

そのため、運用状況とバリデーション報告書、URS・PQまでは、何としてでも査察前に不備がないか確認しておくことをお勧めします。
お時間がない方は、次回からの記事は読み飛ばしてもらっても大丈夫...とは断言できませんので、皆さまのご判断にお任せします。


※:
ユーザ要求の各項目が、設計書のどこに記載され、テストのどの項目で検証されているか、紐づけて確認できるようにするための一覧表。



(10:03)

2014年12月17日

こんにちは。

前回の記事までで、システムの運用に問題がないことまで確認できましたね。
ここからやっと、システム導入時のバリデーション記録の確認が始まります。
それなりにCSVを行っていたシステムであれば、相当な量の文書・記録が残っていると思います。
スミからスミまで確認するのは大変なので、ここは「リスクマネジメント」を採用して、優先順位をつけてみていきましょう。

1)バリデーション報告書を確認する。
まずは、バリデーション報告書の存在を確認してください。
もちろん、作成者や承認者の署名付きの原本です。

そしたらあとは簡単です。
バリデーション報告書の内容から、下記の確認をしてください。
(バリデーション報告書には、少なくともこれらを含めておいてください)

ⅰ)必要な文書・記録がすべて作成されているか。
ⅱ)テストがすべて完了しているか。
ⅲ)逸脱(=計画書通りに行わなかった事項)が適切に対処されているか。
ⅳ)発生した障害が全て対処されているか。
ⅴ)CSV期間中に対応した変更が、適切に対処されているか。
ⅵ)運用中の使用制限が設定されている場合、その通りに運用されているか。
ⅶ)SOP(=標準作業手順書)で定められた最終責任者の承認を得て、業務で使用可能な状態となっているか。

ここでは特にⅵ)が盲点になりそうなので、注意して確認してください。
運用開始の時期が決まっていて、全ての障害を修正することが困難な場合などは、その機能を使用せずに運用で回避してシステム本稼働に突入することが多々あると思います。
その場合は、SOPや操作マニュアルに記載するなどして、誰もが誤って使わない環境となっていることを確認してください。






(14:08)

2014年12月15日

おはようございます。

週末は日光・鬼怒川へ会社のみんなと一緒に初雪を見てきました。
温泉でゆっくりし、今年一年の良い締めくくりとなりました。 あと半月残っていますが...残りも頑張ります!

さて、今回はシステム運用状況の確認ポイントを挙げてみます。
3)システムの運用状況を確認する。

ⅰ)日常点検・定期点検の記録を確認

ⅱ)変更管理の記録を確認

ⅲ)逸脱・障害管理の記録を確認

ⅳ)教育訓練の記録を確認

ⅴ)自己点検の記録を確認

ⅵ)是正措置の記録を確認


なんとなく、たくさん書いてあるように見せるため、一行ずつ空けて書いてみました。

記録の有無だけではなく、内容もチェックしてください。
理由もなく未解決の障害が残ってたりしてはいけません。

もちろんこれらの記録は、手順書(SOP)の通りに記録されていることが前提です。


こんなことが起こるはずないと思いますが、なぜか色とりどりの付箋が記録に貼られていたら、剥がしておくことも忘れずに


2014/12/18追記
某製薬会社の運用責任者の方よりコメントをいただきました。
査察では、運用責任者によって変更・逸脱・教育訓練の記録がレビューされているかもチェックされているようです。
システムの運用状況だけではなく、管理状況も重要なポイントなんですね。

csvblog_prof(小)




(10:24)

2014年12月10日

おはようございます。

先週は月~金ブログ毎日更新にこっそり挑戦していました。
昨日サボってしまったため、連続更新記録はストップしてしまいましたが、これからもマイペースに続けて行ければと思っていますので、皆さまどうぞお付き合いください。

さて、今日の本題です。
これまでは、CSV査察で品質保証部門やシステム部門の責任で実施すべき内容を挙げてきました。そこで、今回は使用する側の部署が実施すべき内容を整理したいと思います。

ただし、複数の部署が使用する大規模なシステムについては、こちらも品質保証部門やシステム部門の責任で進めていくのが良いと思います。

1)システム記述書を作成する。
システム記述書の説明は、
こちらで少し触れています。

全てのシステムに対して作成するのは大変だと思いますので、リスクアセスメントの結果を基に優先順を付けて作成することをお勧めします。
この際の優先順位は、事前に品質保証部門やシステム部門が旗振りをして決めていただければと思います。

システム記述書があれば、査察の調査担当者にシステムの説明をする際、バタバタあちこち資料を出さずに、スマートに対応することができます。
これできっと、調査担当者も好印象を持ってくれること間違いなしです!


2)システムのSOP(操作手順書、管理手順書)を見直す。
実際の運用がSOPの通りに行われているかをチェックしてください。
システム運用を始めてみてSOPが現実的ではないと分かった場合は、その都度、SOPを改定ていると思いますので、大丈夫だとは思いますが、念のため、査察前にはSOPが最新の状態に改定されているかを確認してください。

また、以下の運用は、CSVとしても重要なポイントとなりますので、査察で説明責任のあるシステム責任者は、どのように管理されているか再確認をしてください。
●セキュリティ
●バックアップ
●災害対策

3)システムの運用状況を確認する。
CSVの査察対応というと、導入時のバリデーション資料の整備を優先してしまいがちですが、私はまず、運用状況の確認を優先することをお勧めします。

どんなことを確認すれば良いのかは、次回のお楽しみです


つづく...



(09:27)

2014年12月08日

この週末は大雪に見舞われた地域もあったようですが、皆様の周りはご無事でしたでしょうか。

さて今回は、CSV査察準備におけるリスクアセスメント実践編です。
査察とCSV(2) 《CSV査察準備編》で「つづく」としていたその続きを始めます。

3)システムのリスクアセスメントを見直す。
日頃より整備しておいたシステムの一覧に、以下の項目がなければ追加してみてください。
また、既に記載されている場合でも、システムの用途が変更となっていたりすることがありますので、定期的に内容を見直すことをお勧めします。

ⅰ)システムを利用する業務
患者さんの安全性、医薬品の品質、データの完全性に大きな影響を及ぼす工程で使用するシステムは、リスクが高いと判断されます。

ⅱ)システムの主要機能
業務上、重要・複雑な機能を持つシステムは、リスクが高いと判断されます。

ⅲ)導入時期、大規模な変更を行った時期
最近導入したシステムの場合、システム運用が安定していない可能性があるため、リスクが高いと判断されます。

上記を総合的に判断し、システムリスクを評価します。
ここでリスクが高いと判断されたシステムが、査察調査対象の有力候補となります。

査察調査担当者にこれらの項目を記載したシステムの一覧を提示すると、調査担当者もリスクの高いシステムを同じように判断する可能性が高くなります。ということは、なんと、高い確率で査察対象のシステムを事前に予測することができるということです。

リスクマネジメントも、うまく使用すればとても便利な考え方ですので、ぜひ身近なところから練習してみてください。
私は年末の大掃除をリスクマネジメントでやってみようと思います!



(10:07)

2014年12月05日

前回の査察テーマの記事で小出しにした「リスクアセスメント」ですが、これは製薬業界でここ最近主流となってきた考え方です。

CSVを1から10まで完璧に実施しようとすると、大変な労力やお金がかかってしまいます。
これでは、せっかく良い薬を作ろうとしている製薬会社にとって、あまり良い環境とはいえません。
また、10追求しようとして、全てがおろそかになり、重大なミスにつながる可能性もあります。

そこで、PIC/Sなどでは、業務やシステムのリスクを分析し(=リスクアセスメント)、そこで重要と判断されたものについて、特にしっかり対応を施すように述べられています。そして、このようにリスクを分析し、対応を決めていくことをリスクマネジメントといいます。

ここでいうリスクとは、医薬品の「品質」、患者の「安全性」、データの「完全性」に対するリスクです。

厚労省の適正管理ガイドラインでも、PIC/Sの内容を受け継いでいるため、リスクマネジメントの考え方が採用されています。

上述では、CSVを例にとって挙げていますが、リスクマネジメントは医薬品製造過程全体にあてはめることができます。
また、査察時の調査でも同様の考え方が取り入れられているため、査察調査対象としては、リスクの高い業務やシステムが最有力候補となります。

リスクマネジメントをもっと勉強したいという方は、「ICH Q9」で検索してみてください。
私もまだまだ勉強中の身です。
もし勉強の成果が出ましたら、このブログでご報告したいと思います。
(しばらく先になりそうなので、あまり期待はしないでください...)





(10:33)

2014年12月04日

おはようございます。

現在二つのシリーズ(CSVとの出会い編、査察とCSV編)が中途半端な状態になっていますが、今日も気分を変えて新しいテーマに挑戦です。

今回は、治験でのお話です。
医薬品開発の最終段階では、臨床試験(治験)が行われます。
動物などを用いた試験で薬の安全性や有効性が確認された薬は、とうとうヒトで最終確認を行うのです。

治験では、あらかじめ定められた治験実施計画書に従って、治験対象者の症例データや血液データなどを収集し、薬の安全性や有効性を確認します。
薬によって効能が違うので、収集するデータはそれぞれ違ってきますし、治験の段階によって治験対象者も健常者から患者さんへと変わってきます。
治験と一言で言っても、色々なパターンがあるのです。

そのデータはEDC(Electronic Data Capture)というシステムで収集されています。

ここからが本日の本題です。

昨日、EDCを用いて治験のデータマネージメント業務を行っている方とお話する機会がありました。

色々なパターン(プロトコル)をEDCに登録する際、どこまでのCSVを行えばよいか社内の検討事項となっているとのことでした。
プロトコルの登録は非常に細かく、その設定を間違えてしまったり、うまく機能しなかった場合、治験の結果に重大な影響を与えることとなってしまうので、慎重に対応しなければなりません。
そのため、そのプロトコル登録後のテストも重要となる訳ですが、もともと既製パッケージのEDCを使用しているのに、本当に1から10までCSVを行わなければならないのか社内でも見解が分かれているとのことでした。

今回お話しさせていただいた方は、日本の製薬業界をリードしていくことができる立場にいらっしゃる方なので、是非とも、その他多くの製薬会社のために、効率的で効果的な仕組みを作っていただきたいなと思っています。




(10:40)

2014年12月03日

本日は昨日の予告通り、CSVの査察対策について書いてみようと思います。

CSV査察対策シリーズでは、

ⅰ)以前在籍していた非臨床試験実施施設でのGLP査察時での経験
ⅱ)コンサル時代や今の会社でお世話になった製薬会社様からの査察のご報告
ⅲ)PIC/S分科会での製薬会社様や供給者企業様からの体験談
ⅳ)厚生労働省「コンピュータ化システム適正管理ガイドライン」(以下、適正管理ガイドライン)()のお勉強の成果
ⅵ)PIC/Sのお勉強の成果

など、これまでの知識・経験を総まとめして整理してみます。


まず、はじめに準備編です。
査察直前になってではなく、日頃から気にかけていてほしいことを挙げてみました。
ここに書いている作業は、施設の各部署を統括する部門(品質保証部門やシステム部門等。以下、システム部門としておきます)が責任をもって実施するのが適任だと思います。

1)コンピュータ化システムを管理するための手順書(SOP)を整備する。
これは適正管理ガイドラインで要求されていることなので、多くの製薬会社様が開発・検証期間中と運用期間中の両方のSOPをお持ちかと思います。
ここでは、実際の運用がこのSOPの通りに実施されているかを改めて確認してみてください。
SOPの内容のハードルが高く、実際に実施するのが困難な内容になってしまっている場合は、要注意です。CSVの品質を維持したまま、ハードルを下げてみることもできる可能性があります。品質保証部門とも相談しながら、その施設に見合ったSOPとなるよう整備することをお勧めします。

2)査察対象となる全てのシステムの一覧を整備する。
こちらも、適正管理ガイドラインやPIC/Sでも要求されていることなので、多くの製薬会社様がお持ちだと思います。
しかし、ユーザ部門がコンピュータ化システムの定義を狭義で捉えられてしまっていて、システム部門にまで連絡が来ない可能性もあります(例えば、Excelマクロを用いた分析結果集計シートや、PLC内蔵の製造設備など)。
したがって、システム部門は各部署に対して、定期的に新たな機器や設備の導入がないかの確認をすることをお勧めします。

3)システムのリスクアセスメントを見直す。
つづく...

いつものように、いいところ(?)で「つづく」としてみました。
査察のテーマは長~く、引っ張ることになりそうな予感です。


※:
平成24年4月1日より適用となった厚生労働省発出の、正式名称「医薬品・医薬部外品製造販売業者等におけるコンピュータ化システム適正管理ガイドライン」のことを言っています。

正式名称が長いので、私は社内では「あの青い本」と呼んでいます。

これは、医薬品を製造している施設(GMP施設)が遵守すべきCSVに関するガイドラインです。
GMP施設のみならず、CSVを実施する施設やシステム開発会社の方にとっても参考になるガイドラインなので、興味のある方は是非ご覧ください。



(11:45)

2014年12月02日

今回は少しテーマを変えて、リクエストがあった査察について真面目に書いてみようと思います。

製薬業界ではない方は査察と言ってもピンと来ないかもしれませんが、製薬会社にとって査察は一大イベントです。

査察は誰が誰に対して行うの?それは...

皆さまも薬害問題のニュースでは、製薬会社だけではなく、国の責任が問われていることを耳にしたことがあるかと思います。国は国民を守るために害のある薬を世の中に出さないよう責任を持っているのです。

そのため、薬の研究、臨床試験、製造、販売後すべての過程の中で、行政が密に関わり、世の中に出して良い薬かどうかをチェックしています。その活動の一つが製薬会社に対する査察なのです。

そして、この査察をうまく乗り切らないと、薬を製造できなくなったり、薬を販売できなくなったりしてしまうので、製薬会社にとっては、絶対に乗り越えなければならない試練なのです。

そのため、製薬会社が「査察で指摘された」と言ってシステムや設備に改善をお願いしてきたのであれば、最優先で対応するのが、製薬会社に製品を納めた側の使命だと思っています。

ちなみに、以前ご紹介したPIC/Sは、薬の製造過程の査察を、加盟国が協力して行おうとする取り組みです。

今回は製薬業界の外からの目線で査察をご紹介してみました。
次回は製薬会社からの目線で、PIC/S対応も含め、どのようにCSVの査察対応をしたら良いか、私の主観ですが整理してみようと思います。

お楽しみに




(11:17)

2014年12月01日

おはようございます。

昨日、会社の人たちとハーフマラソンを走って来ました。
自己記録は更新できませんでしたが、ギリギリ目標はクリアできました
今年は反省点も出たので、次回は自己記録を更新できるように頑張ります!


さて、本ブログの本題に戻りたいと思います。
今回はちょうど10年前の出来事を回想してみます。

毎日毎日、動物の検査をしていた私たちの部署の責任者が、定期的にPart11委員会という社内の集まりに出席するようになりました。
集まりから戻ってくると、おかしなことを言い出すのです。年代物の分析装置につながっているパソコンに、不正アクセスの形跡がないか調べたいとか、分析装置のメーカーが作ってくれたExcelマクロがどうだとか。

当時の私は、一体何がしたいのか理解できませんでした。
ただ何となく、面倒なことが始まりそうだなという暗雲が、検査室一帯に立ち込めていたのには気づいていたのでした。

つづく




(10:49)