|
１．はじめに
日本は，2022 年4 月からICH 加盟国の中で最初にeCTD
v4,0 形式による医薬品承認申請の受付を開始し，2026 年4 月からこの形式による申請が義務化される。2024
年9 月時点でのeCTD v4.0 による正本申請数は43で，同時期のv3.2.2 による申請数497
に比較すると8.7% と1 割にも満たない1）。申請数の割合は増加しているものの，2024
年9 月時点でも13.5%と過半数には遠い。eCTD v4.0 への移行が進まない理由として，次の点が挙げられる。
・eCTD v4,0 の仕様がv3.2.2
と大きく異なるため，製薬企業（申請者）側で十分な対応がなされていない
・欧米の規制当局におけるv4 の義務化は，早くてもEU（中央審査の場合）で2027 年，FDA
で2029年（2024 年9 月時点で新規NDA については受付を開始）と，外資系企業の対応が進んでいない
しかし，日本での義務化まで1 年を切った現時点では，eCTD
v4,0 への対応は待ったなしである。今回は，eCTD v4.0 の理解とv4.0 への移行がビジネスにどのような影響があるかについて，申請者の視点から重要なポイントを述べる。
２．eCTD v4 開発の経緯
eCTD v4 の仕様を理解するには，その開発の経緯を知ることが必要である。eCTD
v4.0 実装ガイド v1.52）に「3.1 全般的な背景とeCTD
の歴史」に記載されているが，ここではその背景と経緯を補足する。
ICH は2006 年頃，eCTD v3.2 の課題を解決するために，マイナーバージョンアップ版のv3.3
を開発するのか，それともメジャーバージョンアップ（当時はNMV《Next Major Version》と呼ばれていた）を行うのか議論していた。2007
年に開催されたICH 横浜会議で，ICH Steering Committee は，NMV
の開発を承認した。その背景には，FDA のPDUFA（Prescription DrugUser
Fee Act）IV の影響がある。PDUFA IV InformationTechnology
Plan では，医療情報の交換や連携を標準化する国際規格であるHL7 を採用し，規制情報の処理とレビューにRegulated
Product Submission（RPS）を用いることが示された。このような背景から，NMV
はRPSをベースとすることになった。
３．HL7 RPS
RPS は，HL7 v3 規格に基づいた規制対象製品用の標準メッセージ交換様式（電子申請仕様）であり，医薬品だけでなく，医療機器，診断薬，食品添加物など，すべての人用および動物用製品を対象としている。世界中で利用されることを想定しており，各国の規制当局に対応した製品タイプ別のモデルがいくつか準備されている。eCTD
v4 は，RPS のサブセットとなる。
RPS のメッセージは，次の構成からなる。
・Application
各地域・国の規制当局で定義するが，欧米では医薬品のプロダクトライフサイクルを通じたすべての申請（Submission）を構成するものとしている。日本では，医薬品の承認審査プロセス上，Applicationの概念がないため，Submission
と同様のものとして取り扱われている。
・Submission
１つの承認申請に相当し，Submission Unit から構成される。日本のeCTD 受付番号（
例：250301001）に相当する。
・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 とsuspended
のみである。
・Document
eCTD v3.2.2 のリーフに対応する。
・Keyword骨格やDocument の情報をさらに定義するもので，eCTD v4,0 ではCoU
とDocument の両方に関連付けられる。ICH が規定するものと。申請者（製薬企業）が定義できるものの2
種類がある。
図1 はRPS のメッセージ構造を示している。これはHL7 Reference Information
Model（RIM）による表現で，CTD 構造との関連が分かりづらいかもしれない。そのため，RPS
メッセージとCTD 構造とのマッピングしたものを図2 に示す。
図１
図２
４．eCTD v4.0 の仕様
eCTD v4.0 の機能的特徴について，eCTD
v3.2.2 との違いを交えて解説する。
4.1 ハーモナイズされた共通の電子的メッセージ仕様
xml ファイル数を最小限に抑え，ICH 各地域・国間で仕様の違いが生じても技術的なデザインは変わらない。eCTD
v3.2.2 では規制当局ごとに異なるM1 用のregional.xml を必要だったが，v4.0
では1 つのXML ファイルでメッセージを構成する。また，FDA が求めているSTF（Study
Tagging File，eCTD で提出する試験データを構造化するためのメタデータ）の提出も，地域・国ごとの仕様を統一している。この結果，各地域差があっても技術的な仕様の変更は不要になる。
4.2 eCTD v4.0 XML メッセージの特徴
eCTD v3.2.2 では，XML eCTD
DTD（Document TypeDefinition）でCTD の構造を定義し，eCTD
項番号は固定されていた。一方，v4.0 では，CoU によって，必要な情報はすべてコード化して管理している。
例として，v3.2.2 で<m3-2-s-2-3-bv-of-materials>
とDTD で定義していたものが， v4.0 では<code code="ich_3.2.s.2.3"codeSystem="2.16.840.1.113883.3.989.2.2.1.1.1"/>
と表記される。code system とcode を示すことにより，code の参照先とcode
の値を示している。これにより新たなCTD 項番号の追加があった場合，v3.2.2 ではDTDの変更に伴うeCTD
編纂システムやビューワーのシステム改修が必要になるが，eCTD v4.0 では，ControlledVocabulary（4.6
を参照）の更新のみで対応可能である。
◆続きは「月刊PHARMSTAGE」２０２５年３月号 本誌でご覧ください◆
月刊PHARMSTAGEのホームページはこちら
https://www.gijutu.co.jp/doc/magazine_pharm%20stage.htm
参考文献
1）PMDA eCTD 国内情報提供ページ eCTD
提出状況
https://www.pmda.go.jp/int-activities/int-harmony/ich/0009.html
2）eCTD ICH 電子化コモン・テクニカル・ドキュメント（eCTD）v4.0の国内実装について
v1.5.0
https://www.pmda.go.jp/files/000246001.pdf
|
