M2 ICSR仕様書に基づいた、個別症例安全性報告の電子化・電子的伝送の概要を説明する。
データ項目属性定義
M2 ICSR仕様書では、各項目（報告をデータファイルとして考えた場合はデータフィールド）について、フィールド長や書式、コード化の方法など、記入の仕方の詳細を定義している（M2 ICSR仕様書 付録A.1 ICSR属性一覧表）。表1に、その一部を示す。たとえば「A.1.1第一次情報源の国の識別」のような国名や、人の性別はISO規格のコードを用いて記入する。また「A.1.3伝送の日付」のような日付データの場合は、日付の書式と値の対で記録する。A.1.3aにある「日付の書式102」とは、CCYYMMDD（西暦年を4桁、月・日を各2桁で表す）なる形式を表す。「A.3.1.1（送信者の）種類」のようにE2Bガイドラインで回答の選択肢が定義されている場合は、「1=製薬企業,2=規制当局,3=医療専門家,...」のように選択肢のコードを定めている。フィールド長にある記号AはAlphabet（英字）を、ANは英数字（Alphanumeric）を、Nは数字（Numeric）を表し、たとえば60ANとある場合は、英数字60文字で記入することを表す。（日本語で記入する場合は、フィールド長は、この2倍としている。）
表1の太線で囲んだブロック（たとえばB.4で始まる部分）は、繰り返し記入が可能であることを表す。繰り返し可能ブロックの中の一部が、さらに繰り返し可能な場合は、その部分を2重線で囲んで表している（たとえばB.4ブロックの中の「B.4.k.2.2活性物資の名称」）。
電子的交換書式ICH ICSR DTD
M2では、SGML（Standard Generalized Markup Language）とよばれる規格を用いて、個別症例安全性報告（ICSR）の標準書式を定めた。SGMLはコンピュータ間で交換可能なドキュメントの標準フォーマットを記述するための方法で、具体的には交換するドキュメントの内容（項目や項目グループ）をタグとよばれる特別なマークでくくって表現する。タグの付け方、使い方の約束事を定義したものをDTD（Document Type Definition： 文書型定義）とよぶ。たとえば安全性報告という特定のドキュメントを交換したい場合は、安全性報告固有のDTDを事前に定義しておき、個々の安全性報告は、このDTDに従って記入する。これにより、異なるコンピュータシステム間で、安全性報告を交換することが可能となる。M2 ICSR仕様書では、ICH ICSR DTDとよばれる安全性報告のDTD「A.2 ICH ICSR DTD（文書型定義）」を定義している。同DTDは1997年7月にVersion 1.0となり、その後改訂を経て現在はVersion 2.1となっている。図1にICSR DTDの一部を示す。DTDでは、項目グループや項目を要素とよばれる単位で記述する。表1の「DTD記述子」の列には、要素が示されている。図1の最初にある
<!ELEMENT safetyreport - - (..., occurcountry?, ..., (patient, ...))>
なる部分は個別症例安全性報告(ICSR)全体を表す要素safetyreportを定義し、safetyreportは occurcountry, ..., patient等の要素からなることを表している。この中の要素patientは、
<!ELEMENT patient - - (... (..., drug+, summary?))>
なる部分で定義されており、要素patientは、drug, summary等の要素からなることが示される。さらにdrugは<!ELEMENT drug ...>で定義され、activesubstance等の要素からなる。drug+, summary?, activesubstance*などに見られる、?, +, *の記号は、繰り返しの可否を表し、記号?は「1回だけ記入するか、記入しなくともよい」ことを、記号+は「繰り返し可能で、少なくとも1回は記入する」ことを、記号*は「繰り返し可能で、全く記入しなくともよい」ことをそれぞれ表す。?, +, *の記号がつかない要素は1回記入することが必須である。
<!ELEMENT safetyreport - -
( ･･･････
occurcountry?,
transmissiondateformat?,
transmissiondate?,
･･･････
(･･･････
sender,
･･･････
patient))>
<!ELEMENT sender - -
( sendertype?,
senderorganization?,
senderdepartment?,
･･･････ )>
<!ELEMENT patient - -
( ･･･････
(･･･････
drug+,
summary?))>
<!ELEMENT drug - -
( drugcharacterization?,
･･･････
(activesubstance*,
･･･････ ))>
図1 ICSR DTDの一部
個別症例安全性報告の記入
安全性報告を記入する場合は、図2に示すように個々のデータ項目や項目のグループを開始タグと終了タグの対ではさんで記入する。開始タグはDTDで定義される要素を<>でくくったもので、たとえば安全性報告全体の開始タグは、要素safetyreportに対応して<safetyreport>となるので、図2に示すように報告の先頭には<safytereport>を置く。終了タグは、開始タグの<の後に/を置いて、</safetyreport>となり、安全性報告の最後には</safetyreport>を置くことになる。個々のデータは、対応する開始タグと終了タグの間に記入する。たとえば、送信日が1999年12月3日ならば、
<transmissiondate>19991203</transmissiondate>
のように記入する。「B.4 医薬品に関する情報」のような項目グループの場合も、グループに対応するタグ<drug>と</drug>の間に記入する。項目グループを繰り返し記入する場合は、図2に示すように<drug>と</drug>の対を繰り返して用いる。
<safetyreport>
･･････････････
<occurcountry>jp</occurcountry>
<transmissiondateformat>102</ transmissiondateformat>
<transmissiondate>19991203</transmissiondate>
･･････････････
<sender>
<sendertype>1</sendertype>
<senderorganization>エムツー,Inc.</senderorganization>
<senderdepartment>調査部</senderdepartment>
･･････････････
</sender>
<patient>
･･････････････
<drug>
<drugcharacterization>1</drugcharacterization>
･･････････････
<activesubstance>
･･････････････
</activesubstance>
</drug>
<drug>
･･････････････
</drug>
<summary>
････････････
</summary>
</patient>
</safetyreport>
図2 ICSRデータの表し方
ICSRメッセージとメッセージ検証
M2 ICSR仕様書では、安全性報告を伝送する場合に、1回で2件以上の報告をまとめて送信できるように定義している。伝送する場合は、送信者と受信者の識別情報や、送信日時等からなるヘッダ情報を先頭につける。ヘッダ情報と、1件ないし2件以上の安全性報告を合わせたものをICSRメッセージとよぶ。図3に一般的なICSRメッセージの構成を示す。前節では省略したが、ICSR DTDではICSRメッセージ全体を表す要素ichicsrが、次のように定義されている。
<!ELEMENT ichicsr - - (ichicsrmessageheader, safetyreport+)>
すなわち、要素ichicsrはヘッダ情報を表す要素ichicsrmessageheaderと、安全性報告を表す要素safetyreportからなり、safetyreportは繰り返し可能となっている。たとえば2件の安全性報告を含むメッセージは以下のように表される。ただし開始タグ
<ichicsr lang="ja">
<ichicsrmessageheader> ........ </ichicsrmessageheader>
<safetyreport> ......... </safetyreport>
<safetyreport> ......... </safetyreport>
</ichicsr>
___________________________________________
| | | | |
| ヘッダ情報 | 安全性報告1 | ・・・・・ | 安全性報告n |
| | | | |
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
図3 個別症例安全性報告（ICSR）メッセージの構成
記入したICSRメッセージは、非常に多くのタグを含む煩雑なものとなり、記入ミスも起こり易い。作成したデータがDTDに従って構文上正しく記述されているかを検証するソフトウェアをSGMLパーサという。ICSR仕様書では、例としてSPとよばれるパーサ（無償でダウンロード可能）を用いてチェックする方法を紹介している。また、日本語で記入したメッセージを検証する場合には、SGML宣言とよばれる情報が必要となる。SGML宣言は、SGML文書を書く場合に使用する文字（コード系）などの約束ごとを定義する部分である。仕様書ではDTDと共に5種類のSGML宣言を用意しており、利用する言語（文字コード）により適切なものを選択する。日本語の場合は、その中のSJISとよばれるSGML宣言を用いる。
個別症例安全性報告（ICSR）の確認応答
確認応答（acknowledgement）とは、一般に電子的にデータ交換を行う場合に、受信した側が、送信側に対して、受信状況を知らせるものである。M2 ICSR仕様では、安全性報告を受信した場合に、送信側に対して、受信の状況や、必要に応じてメッセージの再送を要求するためのデータ項目、項目属性定義およびICH ICSR確認応答DTdからなる確認応答メッセージ仕様を定義している。確認応答メッセージには、安全性報告の送信者と受信者の識別子、メッセージ番号、受信日時などの他、安全性報告の受信状況として、次のいずれかのコードを記入する。
01= 全ての安全性報告のデータベースロードを完了。
02= 安全性報告にエラーあり。データベースロードが未完了の報告がある。
03= SGMLの構文にエラーあり。ロードは行われない。
SGMLの構文上の誤りがなかった場合は、個々の安全性報告について、エラーの有無と、エラーがあった場合はその内容を返す。エラーとしては、たとえばフィールド長やデータの値、必須データの有無等が考えられるが、詳細については各組織の任意とし、仕様書では規定していない。
データ構造
以下はE2Bガイドラインから得られた個別症例安全性報告（ICSR）のデータ構造である。ボックスは項目グループを表し、ボックスを結ぶ線分は項目や項目グループ間の関係を表す。線分の終端の記号は、項目や項目グループの繰り返し記入の可否を表す。各記号の意味は、以下のとおりである。
1対1関係 : 必ず1回だけ記入する。 例） B.1 患者特性。
1対（0または1）関係 : 1回だけ記入するか、または記入しなくともよい。例）B.1.9 死亡の場合。
1対多関係: 繰り返し記入可能。少なくとも1回は必ず記入する。例）B.4 医薬品に関する情報。
1対（0または多）関係: 繰り返し記入可能。全く記入しなくともよい。例）B.4.k.2.2 活性物質の名称。
同図はデータベースを設計する際の参考となるが、ICSR仕様書ではデータベース設計はユーザの任意とし、特に規定はしていない。