2020.05.22.FRI

開発薬事

基礎から学ぶeCTD【第4回】

この記事を印刷する

執筆者:松井 一

基礎から学ぶeCTD【第3回】

eCTD v4.0の概要(2)

はじめに
 eCTD v4.0は、eCTD v3.2.2を運用後に規制当局ならびに製薬企業から出てきた改善要求等を満たすように開発された。その際、ICHはeCTD v3.2.2に新たな仕様を追加して、v3.2.3のようなマイナーアップグレードを行うのではなく、v4.0として、メジャーアップグレードの方法を選択した。その結果、eCTD v4.0は、前回解説したように電子的仕様は、eCTD v3.2.2と互換性がまったくないものになった。今回は、新たな電子的仕様をベースにeCTD v4.0で追加された機能について、解説する。

1.    eCTD v4.0によるeCTD仕様の改善点
 eCTD v4.0において、eCTD v3.2.2から改善された主な仕様について以下に示す。

・ ハーモナイズされた共通の電子的メッセージ仕様
 xmlファイル数を最小限にし、内容がICH各地域・国毎で差が生じても技術的なデザインは変わらない。現在、各規制当局別に異なるM1用regional.xmlを廃止し、1つXMLファイルでeCTDメッセージを構成する。eCTD v3.2.2では、モジュール2からモジュール5は共通の仕様であったが、モジュール1については地域・国毎に異なっていた。また、FDAはSTF(Study Tagging File)の提出を別途求めているが、EMAやPMDAは求めていない。一方、eCTD v4.0では、地域・国毎の仕様をハーモナイズし、1つの仕様にまとめた。その結果、各地域・国でeCTDの運用に差が生じても技術的な仕様(デザイン)に変化は生じない。これは、eCTDツールを作成するベンダーにとっては、福音であろう。これまで、日米欧のeCTDの提出先毎にその地域・国の仕様に合致したシステムを開発する必要があり、更に、GCC(Gulf Cooperation Council)やタイのように後からeCTD形式での医薬品の承認申請を受理する地域・国が現れた場合、ツールベンダーはシステム上それに対応する必要があったが、eCTD v4.0以降では大幅にその作業が軽減され、これまでより迅速に対応がなされると思われる。

・ Context of Useライフサイクル
 1つのCoUを複数のCoUで置換ができる。また、その逆も可能である。これは1申請内で提出するたびに、特定のCTD項番号配下にあるドキュメントの数を変更することができることを意味している。また、keyword(drug substance/product names, manufacturers, dosage forms, indication, excipient, etc.)の表示名を変更する際、eCTDのライフサイクルを回すことなく変更することができる。これは、製品名を間違えた場合にそれを訂正する際、便利な機能である。

・ Controlled Vocabulary
 Controlled Vocabulary(CV)はeCTD v4.0 の構成要素の一つであり、XMLメッセージの送信システムと受信システム間の相互運用性を高めている。XML 要素にコード値が含まれている場合は、その概念の値を指定するためにCVが必要となる。各コードにはコード・システムが適用される。コード・システムはICH、地域、または申請者によって管理されている。eCTD v4.0では、1)ICHが規定、2)各地域が規定、3)HL7が規定、4)外部団体が規定する4種類のCVがある。
ICHが規定しているCVの一例として動物種(マウス、ラット、イヌ等)、地域のCVの一例として規制当局であるFDAが規定している申請種類(NDA、IND、ANDA、BLA等)、HL7が規定しているCVの一例ではStatusコード(active)、外部団体が規定しているCVとしてISOの言語コード(英語:en、日本語:jp)がある。申請者が定義するvocabulary(keywordDefinitions.value.item.code)は、codeおよびcodeSystem 値を使用して定義する。申請者は、これらの値に独自の割り当てを使用してもよいし、OID 割り当てを使用してもよいが、必ずしもそれに従う必要はない。規制当局はこれらの値を1つのApplicationの中で使用するので、当該Application内でのkeywordコード値の使用に関して重複等の問題があってはならない。申請者が定義するvocabularyとして工場名や製品名がある。これらのvocabulariesがkeywordとして、使用される。

・ フォルダ構造
 フォルダ構造もeCTD v4.0ではeCTD v3.2.2と比べると、階層化がよりフラットな構造になった。eCTD v3.2.2では、eCTDビューワーがなくとも、CTD構造に近い形式であるフォルダを辿ることにより、レビューしたいドキュメント(ファイル)に辿り着くようにするため、階層構造の深い構造になっている。フラットなフォルダ構造を改善と受け取るかどうかは個人の判断によるが、eCTD v4.0の仕様の元になっているRPSでは、そもそもフォルダ階層がないので、それに比べるとeCTD v3.2.2との折衷案的な構造である。M2は、配下のファイル数が少ないためフォルダm2しかない。Module 3からModule 5までのフォルダ構造は、図1に示したが、Module 4やModule 5については、試験ファイルを整理するために、図2に示すようなフォルダを追加することが可能になっている。追加フォルダに関しては、地域毎の実装ガイドで規定されている。
 
 

 

1 / 2ページ

松井 一

松井 一

外資系製薬企業にて、20年以上に渡り、R&D情報管理ならびにCSVに従事した。2012年からは、株式会社シーエーシー、CACエクシケアおよびCAC クロアにて、製薬R&Dの情報管理、CSV、および申請業務に関する業務コンサルティング、CRO業務の品質保証や信頼性保証を行った。現在は、シーエーシーにて、デジタルヘルスソリューションのアドバイザーを務めている。
eCTDに関しては、ICH M8にエキスパートとして参加し、eCTD v3.2.2のメインテナンスならびにeCTD v4.0の仕様策定に従事した。