2020.04.24.FRI

開発薬事

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

この記事を印刷する

執筆者:松井 一

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

eCTD v4.0の概要

はじめに
 前回ならびに前々回の2回にわたって、現行eCTDの仕様であるv3.2.2について、その概要を解説した。次世代eCTDであるv4.0は、2015年のICHジャクソンビル会議でStep 4の合意に達し、Step 5に向けて、ICHに加盟している各地域・国の規制当局で準備が行われている。なお、ICH加盟の地域、国がすべてeCTD v4.0へ移行するのではなく、2020年3月時点で移行を表明しているのは、日本、米国、カナダ、EU、スイス、オーストラリアである。イギリスについては、BREXITの影響で未定である。
 eCTD v4.0での受付開始については、2019年時点では、米国、カナダが2021年中としていたが、これも不透明になっている。これらの懸念事項があることは事実であるが、FDAが2020年2月にeCTD v4.0 Technical Conformance Guideのドラフト版を公開し、パブリックコメントを募集していることから、導入に向けて進んでいることは確かと思われる。今回は、eCTD v4.0の基本的な仕様について、解説する。

1.    HL7のRegulated Product Submission 
 eCTD v4.0は、HL7のRPS(Regulated Product Submission)規格を技術的仕様のベースにしている。RPSは、HL7の規制対象製品用の標準メッセージ交換様式(電子申請仕様)で、対象は、医薬品に限らず、医療機器、診断薬、食品添加物(但し、限定はしない)とすべての人用と動物用製品としており、世界中で利用されることを想定し、各国の規制当局に対応した各製品タイプ別にいくつかのモデルを準備しおり、eCTD v4.0はRPSのサブセットになる。
 RPSのメッセージは、次の構成からなる。
・   Application
  各地域・国の規制当局で定義するが、日本以外の各地域・国では当該医薬品
  の医薬品のプロダクトライフサイクルを通した全ての申請(Submission)
  を構成するものとしている。日本ではApplicationの概念がないため、
  Submissionと同様のものとして取り扱う予定。
・   Submission
  1つの承認申請に相当し、Submission Unitから構成される。日本のeCTD
  受付番号(例:220915001)に相当する。
・   Submission Unit
  1つの承認申請内の提出連続番号で識別される提出単位に相当し、ファイル
  や関連情報から構成される。日本では提出(初回提出、専門協議時の提出、
  医薬品部会時の提出)に相当する。Submission Unitの構成、
  submissionunit.xml、sha256.txt(チェックサムファイル)、
  フォルダとファイルからなる。
・   Context of Use
  CoUと省略され、申請ドキュメントの骨格を構成するもので、
  eCTD v3.2.2 のTable of Contents(CTD項番号)に対応する。CoUが
  Documentを参照するので、申請ドキュメントはCoUから参照されなけれ
  ばならない。CoUの状態は、active、suspendedおよびobsoleteの3種類
  があるが、eCTD v4.0で利用できるのは、activeとeCTD v3.2,2のreplace
  に相当するsuspendedだけである。
・   Document
  ドキュメントを構成するもので、eCTD v3.2.2 のリーフに対応する。
・   Keyword
  骨格やドキュメントの情報をさらに定義したもので、eCTD v4.0では、
  Context of Useと Document の両方に紐付く。更にICHが規定するもの
  と工場名や製品名等の申請者(製薬企業)が定義する二種類がある。
 

1 / 4ページ

松井 一

松井 一

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