1

E2B（R3）追加通知について

日本製薬団体連合会

E2B（R3）実装プロジェクト

井上 学

本日のお話

• 追加通知の概要

• これから検討すべきこと

2

追加通知（公開）予定の概要

• 2013年9月17日の通知で「追って通知」とされた部分

• ICH E2Bでの検討結果に伴う変更

• 技術的な部分の補足

• Q&A

3

R2とR3の比較R2 R3

報告様式 SGML XML（HL7形式）

下記2つのSGMLファイル

• ICH項目 (ICSR)• J項目

（J項目も含めた）

1つのXMLファイル

特徴 汎用性が無い（固定化情報） 汎用性が非常に高い

使用文字コード s-JIS （日本語はJISの第一、第2基準まで）

UTF8 (日本語項目でどの文字が使用不可かは追って通知)

添付ファイル 郵送または持参

紙又はPDF電子化した添付ファイルをXMLに同梱可能（ただし、容量制限がかかる予定）

辞書

副作用・病名 MedDRA医薬品 医療用：再審査用コード

一般用：一般用医薬品コード表

治験品：治験成分記号又は再審査用コード又は一般用医薬品コード表

追って通知現在ICHで検討中の医薬品コードの利用も視野

提出方法 電子的な伝送（追って通知）、持参または郵送（CD等報告）

追加通知（公開）予定の概要• 2013年9月17日の通知で「追って通知」とされた部分

– 報告方法

• 電子情報処理組織による報告

• CD等報告

• 紙報告

– R2形式で報告した症例をR3で追加報告する方法

– 医薬品コード

– 添付ファイル

• ファイル容量制限

• 同梱可能なファイルフォーマット5

電子情報処理組織による報告

6

種類 備考 ファイルの容量制限

AS1 • 現在のR2と同じ方式• 技術が古い

• ファイルサイズが、大きなファイルを送ることが出来ない

• 副作用システムとの連動可能

10MB

AS2 • 比較的新しい技術• 欧米ではR2でもこの技術を採用• 基本的に現在のEDIツールにAS2用のモジュールを

追加すれば、使用可能• 現行の電子証明書をそのまま使用することも可能• 副作用システムとの連動可能

50MB

Gateway • 費用は電子証明書のみ

• 別途準備されるツールを使って報告ファイルの暗号化、Ackの復号化をする必要あり

• 副作用システムとの連動は難しい

100MB

R2形式で報告した症例をR3で追加報告する方法

7

• 猶予期間2016年4月から2019年3月まで

• E2B（R2）様式で報告していた症例について追加報告をE2B(R3)様式で報告する場合には、「J2.1a 識別番号(報告分類)」はE2B（R2）における報告分類(英字1桁)をE2B(R3)における報告分類(英字２桁)に読替えて報告すること。

• E2B(R3)様式で報告し、受け付けられた報告については、追加報告をE2B(R2)様式で行うことはできないので注意すること。

医薬品コード

• 欧米で検討中のIDMP（旧ICH M5）の動向が不明確なため、当面はR2と同様の方法で行う

8

ICH E2Bでの検討結果に伴う変更

• ANフィールドの受付可能文字

• Option項目におけるNullflavorの取り扱い

昨年9月に実施した日本でのR3テスト結果のコメントをICHで検討

ANフィールドの受付可能文字2013年9月17日通知

実装ガイドの記載 使用文字

2013年9月17日通知

ANフィールドの受付可能文字結果

ANとJの区別を廃止し、すべてANとし、UTF8であればすべて受け入れ可能とする

Option項目におけるNullflavorの取り扱い

2013年9月17日通知イ．完了報告の際に必ず記載する項目（必須項目（○））必須項目すべてが記載されていないと、完了報告として受け付けることができない。中略また、ヌルフレーバー（null flavor）が許容されている項目の中には、ヌルフレーバー（null flavor）の記載が受け付けられる項目もあるので、詳細は別紙１及び別紙２を参照すること。

Option項目におけるNullflavorの取り扱い

ICH実装ガイド

Option項目におけるNullflavorの取り扱い結果

• ICH実装ガイドでOptionとなっている項目はOption（▲）とする

15

技術的な部分の補足

• データチェック仕様

• 報告様式

– 様式の見直し

– 様式と各項目のマッピング

– 繰り返し項目の表現の仕方

• リファレンスインスタンス

– 16種類のインスタンス提示

16

データチェック仕様

• 必須不要項目の見直し

– ICHの検討結果を踏まえた見直し

– 未完了報告時と完了報告時とわけて表示

• データチェック（ロジックチェック）

– 基本ICHのルールに準拠

• エラーコード

– 項目とコードが一意

– 繰り返し項目にも対応（○番目の繰り返しでエラーとなったことが特定可能）

17

Q&A

• ICH Q&A– R3用の新規Q&A– R2の時に作成したQ&AでR3でも適用になるもの

• 国内Q&A– R3用の新規Q&A– 現行のQ&Aからの見直し

18

企業で検討する事項

• R3報告書作成方法

– 副作用システムのバージョンアップ

– 無償ツール

– その他

• 報告方法

– 電子的伝送（3種類）

– CD等報告、紙報告

• 副作用担当者の教育

• R2とR3

R2とR3の両方で送受信できる必要あり

R2 and R3各報告先のR3対応時期は、必ずしも同時ではない。

海外規制当局

自社

海外HQ

提携会社A 提携会社B

PMDA

R2

R2

R3

R3

R2 and R3

• データベースの観点から

1. 項目の変更部分

2. 出力ロジックの理解（R2及びR3）3. 取り込みロジックの理解（R2及びR3）4. 地域要件の理解（シングルグローバルデータ

ベースの場合）

1.項目の変更部分

A) 新規項目

B) データベース構造が変更になった項目

C) 見た目は同じだがデータ長などが変更になった項目

理由は？

I. ICH E2B R3対応

II. 地域要件（日本だとJ項目）対応

1.項目の変更部分

A) 新規項目

B) データベース構造が変更になった項目

C) 見た目は同じだがデータ長などが変更になった項目

臨床経過、治療措置、転帰及びその他の関連情報を含む症例の記述情報

R2: B.5.1 40,000J（40000バイト、日本語だと20,000文字）R3: H.1 100,000 J (R3だと文字数で統一、つまり日本語でも100,000文字)

R3対応のデータベースの文字数は？もし100,000文字にしてR2のB.5.1でもこの項目を使う場合、R2での文字数以上にデータが入っていた場合どうなる？

R2 and R3

• データベースの観点から

1. 項目の変更部分

2. 出力ロジックの理解（R2及びR3）3. 取り込みロジックの理解（R2及びR3）4. 地域要件の理解（シングルグローバルデータ

ベースの場合）

R2とR3の両方で送受信できる必要あり

R2 and R3各報告先のR3対応時期は、必ずしも同時ではない。

海外規制当局

自社

海外HQ

提携会社A 提携会社B

PMDA

R2

R2

R3

R3

4.地域要件の理解（シングルグローバルデータベースの場合）

• 日本の症例を英語を含めて日本で入力して完結させる場合

– 他国の地域要件も理解した上で入力する必要がある

– 地域ごとに異なる定義の理解• データチェックロジック

• 添付ファイルサイズの上限、提出可能フォーマット

• 日本にルートされた海外症例も同様– PMDAの地域要件を必要に応じグローバル入力者へ伝えて徹底してもらう必要もある。

これからの予定

• 通知発出（Coming soon）• パイロットテスト 2015年4月‐（予定）

• Q&Aの追補（必要に応じ）発出

• グリーンブック発行

• 2016年4月 R3受付開始（R2でも報告可能）

• 2019年3月31日 R2での報告終了